I am starting work on a new project, in principle, today and have started ordering parts to put my plans into action. Its easier to change things on paper than in copper so I thought I would be more transparent in my development process this time, hopefully people will have some thoughts.
The goal is a: high quality, minimum cost, easy, open, networked audio player.
I still like my stereo but the lack of convenience of physically loading discs into a significant. I also obtain digital music sometimes just MP3s sometimes FLAC that does not have physical media to play. High quality audio interfaces exist for PCs and in USB form but don't meet cost/size/power requirements for my living room.
I could put this on hydrogen audio or some audio forum but I think sadly that will result in a lot of FUD. I won't belabor this point but when RF designs are done badly you almost can just look at the board and say yep that person doesn't know what they are doing. Audio is more forgiving and less. To obtain very high performance is hard, to obtain what most people won't hear a difference between is pretty easy.
As some of you might know I had started a project years ago called openHiFi. This was based on a LM3S part and Wolfson DAC. The first prototype worked okay. The software got to a point where I could index a 2.5" hard drive and play any FLAC track on the disc with a serial command. It needed more work though. The digital board produced measurable EM radiation. This was down to it being one of my first PCB designs and a fast number of fast single ended traces on a cheap 2-layer PCB. Fast forward to the present I still have the same desires for a home audio player with an open testable design.
Much of the burden of completing openHiFi was the need for software. When Raspberry Pi came out and then BeagleBone Black, I realized that for non-realtime small volume microcontroller boards like Procyon (on which openHiFi was based) were likely not the best solution. Software ease trumps the slightly reduced cost easily.
With this realization I started to brain storm some options. One of the things I have noticed about consumer hardware is that they do not take audio too seriously. Most cell phones I have had after the cell phone/MP3 convergence sound subjectively worse than the stand alone players that proceeded them. Raspberry Pi is not known for its stellar output from its audio jack. For a long time I2S was not available without a hack. Now it is. I2S is also available on BeagleBone Black (BBB) in principle, though I have to test it, on the black this appears to be fed to the HDMI framing chip. Since those I/Os are sent to the pin header as well it may be possible to simply tap them. I looked extracting audio data from HDMI, while 3rd party boxes do this they generally create SPDIF streams which have worse jitter problems than I2S. Getting access to HDMI directly requires fees I believe.
Jitter may also be an issue with the I2S streams on the Pi and BBB. On the Pi only there is no MCLK output...
Even when I2S exists on a chip as I said jitter on the clocking can make it less than ideal, often times it does not exist, but SPI almost always does.
This consideration led to the formation of an idea of an FPGA based SPI to I2S converter. A CPLD might work as well, but given latencies in the driving I decided buffering would be required to no drop samples. The idea is simple. To minimize phase noise use switch crystals at the true frequency of the stream being output. Support only the common sample rates force resampling of everything else in software. Send the data to several RAM buffers on the FPGA using fast-SPI with a simple 0xFF return for when the buffers are full. This design should practically eliminate jitter, though of course anything produces some jitter and the FPGA is no different, but in principle this may be close to as good as can be done short of an ASIC. At this point I was assuming I would be writing the software as well. I figured I would create a little C program that would handle the streaming to the SPI port in software. Then there would be a need for a software interface to play the files.
The primary author of this project is clearly plugged in to the DIY audio community and he makes some recommendations on USB DACs to use. The most interesting of which is ODAC.
This is an interesting project and as an engineer a breath of fresh air. Objective measurements are always best. Always. You can like whatever coloration of music you want but an objective output + digital processing before rendering should get you any type of sound you want, that's just math. So our goal in producing audio equipment should be objective output with the best possible performance we can manage. The ODAC documentation seems legitimate because it actually tells you very important things like the effective number of bits the board actually is capable of. You can very very easily take a 24-bit DAC and produce 14-bit effective output.
I read every post this guy made about his ODAC design and for the most part it reads well. Apart from jitter on the I2S stream feeding the DAC the other big issue with high resolution DAC stuff is likely going to be the power supply. The creator of the ODAC claims that he has filtered the USB power in a clever way and this let him run it from the USB power. My reply to that is maybe, but the performance of this design is going to be pretty dependent on how good that 5 V power rail actually is.
Thankfully the schematic was published: http://http://www.yoyodyneconsulting.ca/downloads/General/ODAC/ODAC-release.pdf. From this we can see the filtering is not actually that sophisticated. It is just a second order filter and a LDO with a first order output filter. This is the first thing that makes me nervous about taking everything the guy wrote as fact, though I honestly suspect it is. The method however cannot reject high frequency components very well. These are generally above the close loop bandwidth of the LDO and above the self-resonance of the passives. I don't know the later but the former tends to be < 100 KHz depending on the LDO. This may mean these frequencies are not audible but we must remember that any non-linearity will cause mixing and so the high frequencies can be downmixed to audio frequencies. Given the extreme dynamic range specs of audio one must be careful.
The creator of ODAC to his credit spends considerable space discussing the power supply issue, and suggests a worst case remedy of a powered USB hub. This is a fine solution if the powered USB hub's power supply is clean. The other general issue with power is that bad power supplies can create noise on the mains and this can feed into the power supplies of other items. There is no perfect solution. A nice linear transformer though will likely have poor transduction of these high frequencies and the 50/60 Hz and harmonics are not hard to filter.
So if you want an off the shelf solution to me it looks like ODAC + a PCB to let it run off a linear power supply would be a pretty nice one. This would cost over 200 USD though when it was all said and done. Eeep. Given the DAC on ODAC is a 4-8 dollar part this seems excessive.
It also seems a bit silly to have access to an I2S and not use it, instead to use USB transport and then go back to I2S. Its okay in that jitter performance will then be computer independent but it is not ideal in terms of cost. The 200 dollar solution also can be reused. These are good things but it would be nice in my view to have a solution that honestly was affordable and pretty good. Maybe not quite as good as the ODAC but maybe it could be just as good.
Some look better executed than others but all have things that concern me. The DAC choices seem to be fine. The most common seem to be PCM5102A and ES9023. The later seems more interesting to me because of jitter reduction that may be inside with an asynchronous MCLK (http://http://www.esstech.com/pdf/about-jitter.pdf). It is hard to tell just from the datasheets what patents it is implementing. The fact that PCM5102A uses a PLL to create MCLK when not presented with a synchronous one makes me think it would not be good at rejecting BCLK jitter. To do so would hurt the stability of the lock in the PLL. It is possible that the loop filter is cleverly designed. But inherently the integration time has to be short enough for it to remain locked or samples will be lost.
Today I made some simple measurements on my raspberry Pi's BCLK output with my HP 8495E spectrum analyzer. I found the center frequency of BCLK was 1.411251 MHz on a 30 Hz RBW. It is an error of 36 ppm, which is probably just the crystal tolerance. Phase noise is a bit trickier to measure well. A causal estimate with random power supplies is that it is about -54 dBc/Hz at 100 Hz, which is certainly plausible with regular XO clock modules. It is probably better than this though. I'll have to think on how to do a proper measurement of the phase noise.
So to conclude this first post, it I think it would be fun/neat to try to develop a DAC that can be driven by BBB or Pi and uses the Volumio software. It would be nice to measure it objectively as it is developed. I don't own the equipment to do this however.
I feel like most projects on DP are digital, save for maybe some audio stuff. I am wondering how many folks work on analog things and if there is a need in the community for signal sources or other analog test gear that might just not be affordable?
Digital stuff is far less expensive to manufacture and design. I guess the SDR stuff is analog but largely it is re-purposing USB Rx designs with new software...
If you were eagle eyed you might have noticed a small amplifier on my work bench. I am probably going to measure the supply with my scope and a 4 uV signal isn't viewable, nor is the 100 uV of integrated noise power or whatever.
Which is to say I thought of amplifying the noise signal.
Now the question of do I need an buffer for the spectrum analyzer measurement. I think the answer to that is: no.
What we have to ask here is what is the output impedance of the circuit. Let's ignore the filter for a moment. We have a transformer of 2x and then the circuit looking at that transformer would see the channel resistance of the power MOSFETs in the switching regulator. R_on is specified in the datasheet to be 0.5 ohms. Because of the transformer the 50 Ohm load looks like 12.5 Ohm (R *(Np/Ns)^2). Therefore if there were no frequency response we would have 0.5 in series with 12.5 measuring the voltage over 12.5. This is 96% of the full voltage.
But can the supply drive a 12.5 Ohm load? I hear you ask. No it can't at 15 V, but there is no need, there is a DC block. So only the small signal part is driving anything.
So am I being unfair and shorting out the small signal part? Possibly but only if the capacitors look like more than 50 ohms at the frequency in question (I can measure this by using them as AC coupling caps and putting in a AC signal or by measuring the capacitance as a function of frequency to whatever frequency using a lock-in or bridge). Remember the Al electrolytic capacitors are shorts at high frequencies also. At 47 uF, at 1 MHz ideally we are talking about 1/(47*2*pi). Also note the 220 nF blocking cap was considered. It only impacted the lowest frequencies by a few dB. All the important data is I believe in the spectra I collected, specifically where the harmonics their value within a few dBm.
From the former you can see over the range I measured the capacitors will be to object that dominates the impedance (10 KHz - 1000 KHz). Also note that for the configuration in the CDE data the caps become inductive over about 1 MHz. So isn't that a problem? No it shouldn't be because of the inductor in the PI filter. The inductors self-resonant frequency is 20 MHz so it should look like an inductor below that which is to say a very big impedance blocking all the high frequency noise.
Even limited decoupling caps should kill such noise (small NPO ceramics + trace inductance). The output impedance of a post-switcher LDO will also help should more filtering be needed for a particular application.
The output is already adjustable. You just change the voltage you put into the switcher with the first LDO. However post-regulation would still be wise.
I don't think I will add post-regulation to this PCB because that would be better to do "close" to the place on the target board where the power would be used.
I've been working on creating a power supply for supplying nice clean delicious bipolar power to things that need it.
Although I have several lab power supplies any sort of instrument I create that needs to be DC coupled needs a bipolar power supply (unless the signal DC part of the signal is positive definite).
I don't know how many others would need such a supply, and while I tried to consider cost in the design I mostly considered performance. (Chime in if you need them something like this badly).
In some ways this is the worst of both worlds of linear and switch mode supplies: it has to get its DC input from a linear supply so it has the efficiency of a linear supply, and it has a high part count because it is a switcher. It does avoid people getting electrocuted though, which is very important.
It still needs testing under heavy load and I may remove the barrel input and make this a pure slave module for projects before the design is finalized. I am pretty happy with the performance so far.
I don't know if there was any solution. I think I mentioned in the other thread that I originally intended my Eridani board to be used for GPIB, but I didn't get to it. I recently resurrected the idea, I actually designed my board last weekend but mine is going to be a single chip solution to help with costs.
If you are in a hurry there are 50-60 dollar GPIB solutions on eBay.
Okay option 1 monoprice (for whatever reason I didn't think of monoprice as I think of that as consumer)...
They have somewhat commodity computer wire harnesses. Price of < 1 dollar is okay but would probably cause some people to think they could use an ATX supply which could cause things to blow up.
I have some projects that will have off board power supplies. Historically one of the issues with these guys is that the connectors are so expensive that I often have just used 0.1" headers. We are talking 0.5 A at most here at 15 V.
Any tips for cheap good connectors for this sort of task. Of course there are lots of things from Molex but again just not ultra cheap. It always seems cable assemblies are pricier than they should be. I'd like to have at least 4 rails so 8 wires perhaps. Min 4 wires for 3 rails with 1 COM.
Thanks for the useful suggestions in advance.
PS: Must have a real supply source (thus probably not an ebay thing).
I ordered a LPC4330-Xplorer development board (only BGA for LPC4300 currently and doing the work of laying out a board to evaluate the chip isn't worth it to me given my limited free time right now), as time allows (a big if). I will try to get the M0 to do all the dirty USB 2 HS stuff and the M4 to just do something very simple with a datastream. If possible with GCC tools only as I did with Ti's chips. If I get that base worked out nicely it would sort of be like your FTDI + uC solution save one placement on the board rather than 2. Downside is only flashless parts are really in channel right now so another placement for the external flash is semi-required (not as big a deal on a FPGA + uC board which basically also needs that sort of thing).
Everything sounds easy but I'm sure there will be a bit of a learning curve to get this one running smoothly. If and when that happens I will post some throughput numbers and the base code too of course.
I take it back the LPC4300 sounds like the thing to use. The M0 and M4 are more like just having two chips on the same PCB save they are on the same Si. This means I should in principle be able to use the M0 for USB transfer interface and the M4 for each application. I hope I will be able to setup a generic interface and I/O service program on the M0 and then just write application specific code on the M4. If I can get that to work it would open up a lot of possible uses.
I had full speed numbers for AVR 8 and Ti's M3 (LUFA/Ti stacks respectively) It was on the order of MB/s for the Ti as I was indexing entire HDs full of data and had 30 min throughput timings. They may be written down somewhere in my pile of stuff if not I probably have the test code somewhere if people care for the FS numbers (also it was mass storage for the Ti test naturally).
The on chip PHY for the USB 2 HS makes LPC18xx the most interesting micro for me so far. Fewer chips is better for everything pretty much... Better still LPC4300, HS PHY + M4, 200 MHz. Sounds pretty good so far (although the coprocessor M0 seems like it might add misery to programming). I haven't used NXP yet I hope the docs are good.
There is a LUFA clone I think for NXP I think or something like it... I might have to find it.
Thanks for the reply. Any STM stack throughput numbers for VCP? I read for in a LUFA comment that the packet size and windows polling time were most of the slow down. LUFA seems to support HS on AVR32. I'd probably rather use an ARM.
Ti doesn't have any HS USB 2 parts short of ARM9 or greater. FS in oodles.
Having to write my own windows drivers is probably a nightmare (signatures etc), Linux maybe. I could do FTDI but its really rather not.
It might be a good character building experience though...
Given the cost of of just the UTMI transceiver it is conceivable to use FTDI FT232H. I'd welcome suggestions for stacks or silicon or throughput numbers in different standard classes people have reached with canned software/chips.
I can't say for sure but I suspect throughput will be king. Exact timing isn't possible on USB anyway, but gross latency could matter.
I am interested in some projects that would require large data transfers, and although I am aware of some USB 2 micros (Atmel M3 and ST M4s etc) I am not sure if there is a good USB stack to back them (the more open the better but more documentation is the most important).
Also I am not certain what class is typically used for such transfers. Mass storage seems the most common bulk transfer class but I am not sure it is the most appropriate. A very fast serial ACM like thing would be easiest. I seem to remember you can have more than one class on the USB port though, like mass storage + ACM.
In short I need to essentially stream MB/s with commands embedded over USB. Any software/silicon suggestions (other than FTDI) are welcome.
