j4cbo

I use the DAC in my Transporter. Which option?

If you plug it back in soon enough, it won't even stop.

It was oscillating at very low bias, about 25mA with no heatsinks. Now that I've got the larger heatsinks it's still running cool at 75mA; I guess I'll recheck the stability with the higher current. R19-R20 are 2k, the series closed-loop feedback resistor is 1k, and the shunt resistor is 220R, so gain is 5.5 with either feedback point.

I don't have my laptop with the final schematic/board with me at the moment, but this: http://b.j4cbo.com/temp/gbf2.0rc1-sch.png is very close. I'll upload the one that matches the boards that were ordered when I get home. I have two boards up and running now, with a single set of output devices each attached to s22-style heatsinks. Bringup was painful. When I first powered it up I got several volts of oscillation at 10 MHz - yikes! This happened on two different boards and with either feedback point, so I figured it wasn't just a build error. There seemed to be a lot of noise/hash/oscillation/something coming from the VAS stage, so I tried putting a 22pf ceramic between base and collector of one of the transistors on each side; that didn't fix things either. Colin suggested removing one of the paralleled transistors. After doing that it was entirely well-behaved. Later this weekend I'll take it in to a lab on campus with good function generators and get some measurements. After some tweaking (and using the values I have around) I've settled on 2k ohm R17-R18 and 1k in series with the pot. I'm using a 20k pot but the usable range wouldn't be much less with 5k. The oscillation is worrying me a bit. Did anyone else have trouble with using two non-compensated transistors per side in the VAS stage? The only difference I can think of is that I'm using a different version of the PCB layout, but my SMT-only one should have far fewer parasitics, and the circuit itself is identical. I really want to figure out what the most appropriate value for VAS compensation is, but 22pF was the only low-value C0G chip cap I had on hand; I'll poke around and try to find some other values to test with. But even now it's hard to tear myself away from listening... Vortex: are you using the through-hole group buy PCBs, my SMT version, or something else?

Gettin' there.

I'm not sure. The PMD200 is a Blackfin, but I suspect the PMD100 may be hardwired silicon.

You bet. The Touch just runs Linux with Logitech's UI and playback software. It requires a bit of configuration tweaking to get the player to use a different audio device than the built-in DAC and S/PDIF, but some of the other beta testers have managed to get it working, including with a Wavelength async USB DAC.

No, just stereo, quint-amplified.

It's coming along...

That's a stupid amount of money for something that can't possibly cost more than $100 to build - it looks to be one board in a Hammond case with some ultra-simple milled front panels. An utter ripoff. I'm working (slowly) on my own asynchronous USB implementation and may just open source it once it's done.

About $350 worth of parts from Digi-Key. D:

That's exactly what I said.

Same here

Fuck Photomatix.

Looks like a bog-standard Sabre32 implementation with some fancy marketing terms to describe the Sabre chip.

I haven't tried any self-powered drives (since I don't have any), but I'd be very surprised if there were problems. The designers mentioned at one point that the Touch is designed to be able to supply a bit more than the spec requires if necessary, just in case someone connects a drive which tries to draw too much. FLAC works fine. In the "old days" (SLIMP3 and the oldest Squeezebox), the players could only handle a few formats themselves - SLIMP3 only did MP3, and the first Squeezebox handled WAV and MP3. Nowadays, though, all the players can decode more or less anything onboard. I believe the list for the Touch is MP3, FLAC, OGG Vorbis, WMA, AAC, and WAV/AIFF. TinySC doesn't support transcoding, so a format not on that list won't work unless you're running a separate server, but enough is supported directly that it probably won't be an issue. TinySC isn't a rewrite or a separate codebase; it's just the full SqueezeCenter with a bunch of things disabled / removed to keep the memory footprint down. So the only things that are 'lost' are what's been explicitly mentioned. If you feel like hacking around with the device, you can turn some of those features back on (plugins are pretty easy to re-enable; they just won't be supported officially). Months ago I had an early build which hadn't had the Web interface removed yet, and it was the most glacial interface I had ever seen, so don't hold your breath for that one. For scanning nuances, music services, SB2-and-later device support, synchronization, etc., etc., etc., TinySC should be equivalent to the real thing. The rescan process is, sadly, pretty much the same at the moment. They're worrying on improving new file detection in order to better deal with removable hard drives, so who knows where it'll be by release.

I'm one of the beta testers for both the Touch and the Radio, so hit me up with any questions.

Here's the custom version of the board. http://b.j4cbo.com/temp/gbf2-custom-top.png http://b.j4cbo.com/temp/gbf2-custom-bottom.png http://b.j4cbo.com/temp/gbf2-custom-signal.png http://b.j4cbo.com/temp/gbf2-custom-sch.png Notable differences are: - Most resistors are surface mount. Some are still through-hole, for power and ground plane integrity reasons. According to Marc's dissipation, all the small 0805 resistors dissipate well under 100mW, so there should be no heat issues because of this change. - The rail capacitors near the outputs are rail-to-ground, not rail-to-rail. This lets you use only one type of large capacitor, rather than two different voltages; the net effective rail capacitance should be close to the same. - There is no provision for mounting against an angle bracket. The transistors are right up at the edge of the board, for mounting directly to a heatsink. Note that you may want an external heatspreader anyway. This makes the board somewhat smaller. - There are pads for an onboard relay to select between feedback points. This probably shouldn't be changed while the amplifier is running and headphones are connected. - At the bottom of the board, underneath, is sensing circuitry for monitoring voltage, current, and output servo position. This is connected to pads for an Atmel ATtiny24/44//84 microcontroller. There are no programming headers for the microcontroller; the chip must be preprogrammed or used with a chip clip, such as this. The relay is also connected to the microcontroller. I can help people with this part but only to a very limited degree - don't count on it unless you know someone who can do AVR programming. - Pads for a Dallas Semiconductor digital temperature sensor (DS18B20 / DS1822) - A control bus with connectors on opposite sides of the bottom of the board. This allows for daisy-chaining of multiple boards with common 6-pin headers/connectors. I've tried to make all the changes suggested in the prototyping process to both boards, as applicable, but please let me know if anything looks wrong about it. I'll be sending Gerber files for the original and custom versions to luvdunhill soon.

I will be posting details on my version of the board very soon (tonight).

Dammit, you guys

http://b.j4cbo.com/temp/gbf2a.zip

http://b.j4cbo.com/temp/gbf2g-top.png http://b.j4cbo.com/temp/gbf2g-bottom.png http://b.j4cbo.com/temp/gbf2g-signal.png How's that? All the suggestions you made look good to me; if I missed something, it's probably because I forgot, so let me know.

Whoops! Glad that got caught. Thanks.

I was referring to this:

I think this could be the one... http://b.j4cbo.com/temp/gbf2f-top.png http://b.j4cbo.com/temp/gbf2f-bottom.png http://b.j4cbo.com/temp/gbf2f-signal.png