ok, so its a silly name. a hat trick is where you get 3 things in a row.
so here's 3 things in a row: 3 relay attenuators in a single package, controlled by a cpu (arduino-like thing called LCDuino).
I needed an analog volume control for my newly acquired DCX2496 crossover. this passive relay attenuator will do that for me. it runs software I wrote called VoluMaster and I'm now adding support for 'multi-board' configs such as this.
the single vol pot is a motorized knob that takes user input OR shows current vol level as set via a learned IR remote.
each board has 8 latching relays and is populated to cover 127db range in half db steps.
(the project will be open-source once the coding is complete. this is a sneak peek of the project and what it can do).
so here's 3 things in a row: 3 relay attenuators in a single package, controlled by a cpu (arduino-like thing called LCDuino).
I needed an analog volume control for my newly acquired DCX2496 crossover. this passive relay attenuator will do that for me. it runs software I wrote called VoluMaster and I'm now adding support for 'multi-board' configs such as this.
the single vol pot is a motorized knob that takes user input OR shows current vol level as set via a learned IR remote.
each board has 8 latching relays and is populated to cover 127db range in half db steps.
(the project will be open-source once the coding is complete. this is a sneak peek of the project and what it can do).
Attachments
One reason might be that with a pot you have an absolute starting point whereas encoders are incremental so where to begin? Where you left off? Zero?
How do you store the last setting if you want to continue with the last setting at next power up?
I lean toward the encoder just because they don't get dirty/noisy. Is there an encoder with absolute position readout?
G²
How do you store the last setting if you want to continue with the last setting at next power up?
I lean toward the encoder just because they don't get dirty/noisy. Is there an encoder with absolute position readout?
G²
the way its designed, the motor pot 'zooms over' when you use the IR remote. since there are TWO ways to adjust things (ir and manual knob twist) keeping the knob in sync was an important design goal.
the motor shuttling happens in the background. as soon as you hit an IR up or down vol event, the relays go there immediately. the motor pot then starts to scoot over and then settled when its at the right point.
the goal is that the knob is 'always at the last vol setting'. even if you come in via 'out of band' IR and adjust it.
of course you can twist the knob directly and it will read the linear track and find the right vol db that corresponds and go there right away, as well.
rotary encoders suck for 'feel' and they have no concept of absolute positioning. I can grab a pot and put it at max or min very quickly. can't do that with RE's. I can also put the vol at halfway instantly. can't do with RE's.
that's why I did it that way.
exactly. RE's are cheap and easy enough to use but they are sloppy to use in practice (many are and all cheap ones are) and for high end feel, they just don't cut it.
pots don't get noisy when you use them as *control elements*. no audio goes thru mine. vcc is at one end. gnd at the other and the wiper goes to an a/d pin on the cpu along with a small smoothing cap. the cpu reads the a/d pin and if there was a change from last time it updates the relays. if the IR remote sent in a new value, the system knows that and knows it came from 'the computer' and not a human and so it knows the motor must be moved and the pot wiper value used as target value to know when the pot has to be stopped.
Not sure how arduino-like your controller is but I use the Arduino - EEPROM to remember the last volume setting.
This is so true! I have tried a few different encoders and found all the cheap ones terrible. I've settled on a Bourns Pro Audio one, I think its an ENA1xxxx with 128PPR. It turns more freely than a pot but still feels very good. The Avagotech ones are also nice but not cheap.
Either way, very nice work and photography! 🙂
yes, I use the same.
I guess I meant that RE's with index-marked knobs don't really make sense. if you have only in-band ways of changing the volume (the knob via human hand twists) then the knob always points at the last correct location. but add some out-of-band methods (IR remote, maybe even web-controlled) and you now have a sync problem. this is why there's a motor - to solve that 😉
motors are also cool. as a kid I salivated after the motorized pot based adcom preamps. they were so cool and I guess old memories of them inspired the motor-pot part of this.
motor pots are also *very* multi sourced and the quality really does not matter. I like aspects of design like that.
as much as I loved those old adcom mechanical motor pot devices, I grew to hate the clicky clicky nature of the RE's that were taking their place. recently I bought a few logitech duet squeezeboxes. I'm not sure I ever used a WORSE RE than the one that comes on that remote ;( RE's have to be very well done to compete with even the crappiest motor pot. I hate RE's.
cheers 😉
if the pot has a smoothing cap (doing most of the noise control) and the software re-reads each interface and checks for 'bounces' then its not a real issue, at least that I've found. the combo of the cap and the software read-loop seems to quite down any 'wandering pots' 😉
I did see the problem in early prototypes. but those 2 measures have been enough to keep things stable. been running this basic code base and hardware for more than a year now (in devel a long time in quite a number of permutations).
I did see the problem in early prototypes. but those 2 measures have been enough to keep things stable. been running this basic code base and hardware for more than a year now (in devel a long time in quite a number of permutations).
I wish you had told Technics that! I don't know if there's some amount of current pulled through the wiper of those turntable speed control pots that makes them go bad, but SOMETHING causes them to flake out.
I noticed this before, there are cheap $1 switch-contact rotary encoders as used in car radio volume controls, but then the next (only) step up are the "nice" optical ones used for data entry in oscilloscopes and logic analyzers, and they start around $20.
And yes, a microcontroller can save "current position" in eeprom, and after perhaps a second or two with no change in the control (this is so it doesn't constantly update eeprom as the volume is changed, which may eventually wear out the eeprom's write endurance). The processor can be set to then go into low-power mode in which even the clock crystal is turned off, assuring it doesn't add any noise to the device. The encoder's outputs can go to interrupt-enabled inputs that wake up the controller when a volume change is made.
to be really responsive, RE's need to be scanned a lot. a dedicated front-end chip really helps. if your polling loop has other things to do (mine does) then the RE really seems sluggish. as for interrupts, I'm already using them for IR reception and that keeps the interrupt system mostly 'full'. there is also scanning for front panel buttons and of course the pot, itself. later, there will be some kind of handshake to a web back-end on some small plastic linux box.
the logitech transporter has a really nice RE 😉 but those are not easily buyable or practical to design for. motor pots are easy to find - as long as you have a linear track on one of them. (log audio taper motor pots aren't as useful for doing linear-style positioning).
the logitech transporter has a really nice RE 😉 but those are not easily buyable or practical to design for. motor pots are easy to find - as long as you have a linear track on one of them. (log audio taper motor pots aren't as useful for doing linear-style positioning).
all the details that currently exist:
AMB Laboratories DIY Audio • View forum - LCDuino System
the relays are the 'delta1' board. short answer: standard r/2r in series/shunt. online calc (actually useful, I think):
http://www.amb.org/audio/delta1/r2r.cgi
I tend to use 25k for a Z but one board was 16k since it was what got me 'orderable' sets of R's from the same vendor 😉
I tend to play with the Z value until I get a set of R's that all exist at mouser, etc.
I think the main difference is that a (cheap) RE would require debouncing which can be implemented with a 1 msec delay (at most 2). If you can afford that 1-2 msec then it cost the same whether you are polling a pot or a RE. If you are too busy elsewhere, then in an RE you will miss a click, in the pot you will get a jump (up or down) in volume
Thanks for that, very useful.
I think I'll just keep to my 20k standard and work out how to get the values with 0.1% resistors. I'll P2P wire mine so I don't care if I need a couple of resistors to get each value.
missing clicks is annoying. that's one main reason why I avoided RE's.
a quick jump in volume on a pot twist actually seems to fit in just fine. it takes some time to 'run up' the relays and so each time you twist, it takes that value, sends to the relays and by the time they are done, its time to check the pot again. the relays don't follow the pot on FAST twists but it seems to catch up and does not jump to create discontinuities that distract.
a quick jump in volume on a pot twist actually seems to fit in just fine. it takes some time to 'run up' the relays and so each time you twist, it takes that value, sends to the relays and by the time they are done, its time to check the pot again. the relays don't follow the pot on FAST twists but it seems to catch up and does not jump to create discontinuities that distract.
PS: I was using a different topology of relay controlled attenuator before today, but this is neater. Your calculator makes it much easier and is greatly appreciated.
I'm in the process of developing my own system controller to do the VC for the PGA2310's, the relay attenuator, mains control of all devices, and RS232 control of my AVR, projector, DEQX (when I get it) and new OPPO BRP (also on the soon-to-buy list) all using a Mikroe ATMEL board and probably ported to an Arduino or similar when it's finished. I haven't done much embedded control in a decade or so after designing automotive EMUs and this is to get me back into it again.
I'm in the process of developing my own system controller to do the VC for the PGA2310's, the relay attenuator, mains control of all devices, and RS232 control of my AVR, projector, DEQX (when I get it) and new OPPO BRP (also on the soon-to-buy list) all using a Mikroe ATMEL board and probably ported to an Arduino or similar when it's finished. I haven't done much embedded control in a decade or so after designing automotive EMUs and this is to get me back into it again.
there is an explosion of 'controller meets audio' that I'm seeing, say, in the last 6mos to 2 yrs, tops. its kind of exciting. major new steps up in DIY.
I started with PGA chips and had some fun; then got strong-armed into doing relays (lol). so I did relays and had some fun. there might be other engines you can attach to the controller. then some time in abstracting it enough so that it really is a plug-compatible set of interfaces (ui's and vol control engines). then add i/o switching. then (or even earlier) add remote web (and other) control. the arduino is a great 'local' controller but its sorely lacking in ip/stacking (grin). together they make a pretty good and modular setup.
someday, I'd like to see a true audio control bus that's as standard and inter-operable as tcp/ip is today. for the control side, I'm going to 'punt' and glue on a linux box (seagate dockstar is a current cheap SoC kind of board that runs stock debian on usb stick) and use that linux board as a remote IP and web front-end for *real* remote control 😉
I started with PGA chips and had some fun; then got strong-armed into doing relays (lol). so I did relays and had some fun. there might be other engines you can attach to the controller. then some time in abstracting it enough so that it really is a plug-compatible set of interfaces (ui's and vol control engines). then add i/o switching. then (or even earlier) add remote web (and other) control. the arduino is a great 'local' controller but its sorely lacking in ip/stacking (grin). together they make a pretty good and modular setup.
someday, I'd like to see a true audio control bus that's as standard and inter-operable as tcp/ip is today. for the control side, I'm going to 'punt' and glue on a linux box (seagate dockstar is a current cheap SoC kind of board that runs stock debian on usb stick) and use that linux board as a remote IP and web front-end for *real* remote control 😉
Last edited:
what is NOT drawn is the final R in parallel. that is the same as the Z you picked. the web gui does not show it but its supposed to be implied. for the circuit to work right it does need that final 25k (or whatever you picked) between the 2 output wires, in parallel. stupid web guis. they're not so smart afterall - doh!
- Status
- Not open for further replies.