[Juaquin]

Just wanted to say I am very excited for the relay volume board in particular - I'm building a GainClone and using my own Arduino solution for other things, but relay volume control will be the final touch.

 

[jtostenr]

Hmmm...strange, I thought I had posted this already, but now it's gone.

Anyway, how difficult would it be to incorporate a switchable input attenuator into the LCDuino? I suppose it would take adding a few resistors, a relay and some code, right? Maybe something that could be done on the perfboard section of the LCDuino.

 

[amb]

The relay-based volume attenuator will have 256 steps which should remove any need for an additional attenuator...

 

[jtostenr]

Do you mean there would be no need for one of these?


Quote:

Originally Posted by amb /img/forum/go_quote.gif If you're using a source that is "too hot", then you might want to add an input attenuator at the amp. Here is a schematic of a switchable attenuator. It is drawn for an unbalanced (2 or 3 channel) amp, for a 4-channel balanced amp you'll need to double everything for the negative signal, and use either a 4PDT switch, or two DPDT switches. If you use the same value for all the resistors, then the attenuator will drop the effective gain of the amp by one half (-6dB). A good value to use is anywhere from 10K to 47K.

 

[amb]

Yes, with conventional pots, when you get near the bottom of its adjustment range, channel tracking is usually at its worst. Ordinary stepped attenuators don't suffer from this, but the steps are usually too big near the bottom. These factors make the volume control less than useful when you're using really sensitive low-Z headphones and the amp has high gain. However, with the relay volume stepper we're designing, we'll have 256 steps of adjustment with excellent channel tracking. This means that you should not need to pre-attenuate.

 

[jtostenr]

Great! Thanks Amb

 

[linuxworks]

we're planning on 8 relays or 8 bits. but you can, if you wish, depopulate any # of bits and save on relay cost and relay 'clatter' noise if you are happy with a 0-127 range of steps (for 7 bits) and 0-63 for 6 relays. you can edit the software and tell it you only have 6 relays installed and that you want the steps to be X dB, etc. being open-source, you can do anything you want to customize it for your install.

you can compute the value of the R's when you decide on the # of bits, output Z that is desired, step size (per increment of volume) and so on. the max is 8 relays since chips and machine-bytes prefer things in multiples of 8

but realize that you are free to pick a lower number if you want. as long as you update the software (examples will be given) and make it match the hardware you built, it will work.

my proto was 7 relays and I used 1dB as the step size. I've been using that for a while and I like this config. it saves on 1 relay and some relay noise and I, personally, don't see the need for half dB steps (even though the software allows for single dB and half dB steps) and a single click-up or down gets me a single dB and that works pretty well in the real world. and the range of 0dB (straight thru) to 127dB (near total mute) is more than enough for me!

you COULD build yours to go from 0dB to 255dB in 1dB steps but I'm not sure you'll find much use below 90 or 100dB of atten, in real world use. but you COULD build this to run in that range. no problem. maybe you want a lab grade atten (this passes DC, of course) and you really do want to atten that low (for non audio use). this module can do that. you have 8 bits to play with and you can map the native 0..255 range of those 8 bits of anything you want. if you want 0..255 to be 0-127dB in half db steps, that 'fits' in 8 bits also, so that is a valid configj, as well.

 

[Beefy]

How do you find the relay solution compares to your PGA 23** solution? Sound quality, difficulty to implement, any perspective would be great......

 

[luvdunhill]

Quote:

Originally Posted by Beefy /img/forum/go_quote.gif How do you find the relay solution compares to your PGA 23** solution? Sound quality, difficulty to implement, any perspective would be great......

I believe LinuxWorks "abandoned" the PGA approach.. I think it's mentioned somewhere above in this thread, or in another thread

 

[Beefy]

Quote:

Originally Posted by luvdunhill /img/forum/go_quote.gif I believe LinuxWorks "abandoned" the PGA approach.. I think it's mentioned somewhere above in this thread, or in another thread

I didn't see that. I thought the two approaches were being developed in parallel.

 

[luvdunhill]

Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif I took a detour to try out a digital pot and see if it was usable directly in the audio path. turns out it wasn't. oh well. but wouldn't know that until I tried. also got some experience which will pay back later, I hope

.

 

[Beefy]

Huh, well there you go then. Lucky that I got my digital volume control somewhere else then......

 

[linuxworks]

Quote:

Originally Posted by Beefy /img/forum/go_quote.gif How do you find the relay solution compares to your PGA 23** solution? Sound quality, difficulty to implement, any perspective would be great......

the pga solution was good in some ways and more troublesome in others. I have not at all abandoned it but the first prio was for relays. I think the beta group (email list) also seemed to feel that the relay atten was the better one to implement first.

I've built at least 3 air-wired or perf board pga volume control engines and some worked very well and some not. there are a lot of variables to iron on to get this perfected and we didn't think it was worth the development time to *perfect* the pga style board when the relay board was an easier (and technically) better 'win'.

the long-term architecture, as I see it, is to be engine-agnostic as much as possible and allow for the lcd1 to control relay banks and/or pga style chips and/or LDR style devices. (one neat thing about ldr's is that it could be used in the feedback loop of an op-amp and effectively be a smooth true-gain control, in addition to an input attenuator also being present).

so, first supported 'client' would be a relay board but that's not to the exclusion of others. just an ordering of what makes sense to hit and develop, first.

 

[linuxworks]

Quote:

Originally Posted by luvdunhill /img/forum/go_quote.gif .

my own words:

"I took a detour to try out a digital pot and see if it was usable directly in the audio path. turns out it wasn't. oh well. but wouldn't know that until I tried. also got some experience which will pay back later, I hope."


and so I tried a real simple digital pot in the audio path and it didn't work out. I still have other plans for that digital pot (...) and so it was never wasted work.

this was not intended to be a PGA replacement, btw. the PGA is still a good 'mid-fi' chip as there are times when having that 31dB of gain is very useful! I've said this before, but when watching a DD5.1 movie that is downmixed to 2.0 (for spdif use) my source cuts things by at least 10dB and the content is often buried under that, as well, to allow for headroom. as a result, even setting the atten at 0dB and letting my dac run full-force is not enough to be able to hear the movie dialog. in those situations, you really do want/need gain and its nice to have that available. its also nice to have smooth volume swings between adjustments and that's possible with the solid state volume engines; not so much with chattery relay banks.

on a home theater setup, I could even envision a hybrid of relays and PGA style. especially when you have 6 (5.1) channels or even more to have to manage and vary at the same time. I'd hate to hear that many relay banks going on and off at each volume twist!

 

[linuxworks]

Quote:

Originally Posted by Beefy /img/forum/go_quote.gif I didn't see that. I thought the two approaches were being developed in parallel.

more than two

one thing that benefits from concurrent multiple 'client' development is that you get to generalize the control aspect and get the code 'right' earlier than if you had to adopt some new style of client and 'merge that in'.

quite a bit of code (and assumptions) had to change when I straddled the line between talking to relays and pga chips. it was a good exercise and very useful in coming up with the abstraction needed to make this work.

don't forget, this is a research and design project; so rushing things isn't really helpful. I know people are eager to get hold of these things but rushing a design this complex too soon is not what anyone really wants to see happen.

and just to give some numbers to the software size and complexity, for grins, here's some numbers:

% wc -l *
751 IRremote.cpp
92 IRremote.h
122 IRremoteInt.h
646 LCDi2c4bit.cpp
168 LCDi2c4bit.h
102 config.h
292 ds1302.cpp
110 ds1302.h
102 lm35.cpp
56 lm35.h
104 lm75a.cpp
54 lm75a.h
118 mcp23xx.cpp
73 mcp23xx.h
320 pga23xx.cpp
94 pga23xx.h
4885 volumaster_2_31.pde
146 x10.cpp
36 x10.h
8271 total

roughly 8000 lines of C code in this project, so far. not exactly a small project. the UI has many advanced features and we want the whole system to work and have future expansion ability without re-doing a lot of the code.

we do believe that the feature set and architecture offered will be worth the wait