Head-Fi.org › Forums › Misc.-Category Forums › DIY (Do-It-Yourself) Discussions › Arduino based passive analogue input selection & volume control
New Posts  All Forums:Forum Nav:

Arduino based passive analogue input selection & volume control - Page 3

post #31 of 123
id love one of these working specially
post #32 of 123
Thread Starter 

The basic switching

The basic switching between inputs is most probably the easiest part:



B1L and B1R is balanced input 1
S1L and S1R is single ended input 1

B2L and B2R is balanced input 2
S2L and S2R is single ended input 2

OBL & OBR is the balanced output.

CIS is the single ended input of the single ended to balanced converter
COBL and COBR are the outputs of the single ended converters

With the relays K1-K4 you can switch between the two inputs (you need a lot of relays though)

With the relays K5 & K6 you can choose if the input is going through the Single ended to balanced converter.

It is of course easy (and will consume a massive amount of relays to enhance this schematics to 4 input channels.

Next is the control circuit. Since this will be the most interesting part.
post #33 of 123
I wonder if some R's (like 10k) would make sense on the relays? that way there is no such thing as a fully 'open' circuit.

or, I suppose you could engage a mute relay, do an input selection and then unmute.

then again, if the switching is fast enough, maybe the 'open circuit' problem is not a real life problem. on manual rotary switches, where a user could be 'slow' to turn it, you don't want any open circuits during state transitions; but maybe the relay bank won't need it.
post #34 of 123
Thread Starter 
Quote:
Originally Posted by linuxworks View Post
I wonder if some R's (like 10k) would make sense on the relays? that way there is no such thing as a fully 'open' circuit.

or, I suppose you could engage a mute relay, do an input selection and then unmute.

then again, if the switching is fast enough, maybe the 'open circuit' problem is not a real life problem. on manual rotary switches, where a user could be 'slow' to turn it, you don't want any open circuits during state transitions; but maybe the relay bank won't need it.
You are more than completely right. This is just the basic of switching.
The 10K resistors are an very import ant & interesting idea to prevent 'open circuits'.

The relay control is completely out of scope for this phase. I do not know (and will test out) if the chip (cpu or some interface chip) is capable of doing all the switching all by itself or if it needs some kind of H-bridge.

There will be no muting in the switching circuit. This will be done by the volume control. It will go to mute during switching.
post #35 of 123
one thing to think about is the timing on 'make before break' or 'break before make' on the relay switching.

that's one nice thing about having a cpu there; you can play around with that and not be stuck by some hardware chip that only works 1 way.
post #36 of 123
Thread Starter 
Quote:
Originally Posted by linuxworks View Post
one thing to think about is the timing on 'make before break' or 'break before make' on the relay switching.

that's one nice thing about having a cpu there; you can play around with that and not be stuck by some hardware chip that only works 1 way.
You are right.

I think an bus-like approach is much more promising, easier to control and design. At the expense of some relays.

So next step will be redoing it in bus style.

But I am still unsure about the SE->Balanced conversion. But a a very good solution, with the possibility to omit it and hook in your own favorite implementation is a good thing.

Give me some days and I will come up with an design.
post #37 of 123
At the most you just need a simple transistor, diode, resistor setup for the switching of the relays.

I think the idea of a mute relay is great. With the sensitivity behind some amps and the fact that switching is going to create at least some noise depending on the relays chosen you could end up with some nasty pops. It also keeps as much out of the signal path as possible.

If, however, you go with some reed relays they could be driven directly by the MCU.
post #38 of 123
one of the initial (I think) decisions is: latching vs non-latching relays.

pros and cons of each approach; but you have to pick this early on and have good reasons for why you went with it.
post #39 of 123
Thread Starter 
Quote:
Originally Posted by DKJones96 View Post
At the most you just need a simple transistor, diode, resistor setup for the switching of the relays.

I think the idea of a mute relay is great. With the sensitivity behind some amps and the fact that switching is going to create at least some noise depending on the relays chosen you could end up with some nasty pops. It also keeps as much out of the signal path as possible.

If, however, you go with some reed relays they could be driven directly by the MCU.
I will re do it bus like. So you can hook up (or off) any input from the bus. By that you do not need a muting relay. But you will use more relays anyway
But the whole thing will go easier.

The driving circuit is not included yet.

Quote:
Originally Posted by linuxworks View Post
one of the initial (I think) decisions is: latching vs non-latching relays.

pros and cons of each approach; but you have to pick this early on and have good reasons for why you went with it.
I am planning for using latching relay. You will have only short current pulses and by that you do not have to fear that the digital circuit can affect the analogue circuit that much. Perhaps I will throw in some RC delay to avoid sharp square waves.

To go better safe than sorry I am planning to implement one super easy H-bridge: Steve Bolt's H-Bridge

Linuxworks, you have experimented with latching relays - did you encounter some situations that must be taking care of?
post #40 of 123
that's a nice little h-bridge

that works; or the standard go-to part, l293d. the chip is affordable enough, for me; and a simple drop-in for when you need 2 h-bridges. I use that chip more for motor pot controls (one h-bridge for the main spkrs and one for the subwoofer level, say).

re: latchers; I tried one approach with an 'enable line' (global to the whole bank of relays) and then a toggle-A and toggle-B line for each. you'd hit the toggle line AND the global enable, hold enable for a short bit and then let it go. that sort of worked the first way I configured it; with 1 8bit port expander and an inverter to keep the 'other side' of the relay always opposite of the single control bit for that relay. it had voltage surge issues that could be solved but I gave up and am now going to try 2 controllers; one bit for each side of the latching relay and no global enable 'line'. it also gives more control over each bit of timing.

another hint: port expanders and arduinos can put their pins in high-z mode, so you can EITHER keep both relay pins at the same potential (both bits 0 or both bits 1); OR you can do a combo of 01 or 10 to toggle them; then bring one of the lines into high-z (set it as pinMode(input)) and you break the circuit, leaving the relay in the desired state but not drawing any current at all.

for a better executed solution, you -may- need (or want) to opto-isolate. maybe.

or use ULN2003 style driver chips.
post #41 of 123
Nice project!, may I suggest a straight pass through option bypassing the PGA? Needed if one you of your sources is a DAC with s/w volume control.
post #42 of 123
(seems all the aardvarks are coming out of the woodwork for this thread, lol!)

perhaps an 'extended mute' function would either mute, pass-thru or bypass the vol control element.

the bypass can be a nice a/b compare switch, as well; in case you want to see the effect of the PGA chip at unity gain.
post #43 of 123
Thread Starter 
Quote:
Originally Posted by glt View Post
Nice project!, may I suggest a straight pass through option bypassing the PGA? Needed if one you of your sources is a DAC with s/w volume control.
good point - will be included.

Quote:
Originally Posted by linuxworks View Post
[...]
perhaps an 'extended mute' function would either mute, pass-thru or bypass the vol control element.

the bypass can be a nice a/b compare switch, as well; in case you want to see the effect of the PGA chip at unity gain.
will be included

I think all this is possible. I will schoose some kind of bus/filter approach (as defined in computer sciences).

So that you can connect any input to the bus and can send the signal from the bus through a number of filters (e.g. single to balanced or volume control or what ever

Will cost a number of relays - but will give better flexibility.

Quote:
Originally Posted by linuxworks View Post
that's a nice little h-bridge
re: latchers; I tried one approach with an 'enable line' (global to the whole bank of relays) and then a toggle-A and toggle-B line for each. you'd hit the toggle line AND the global enable, hold enable for a short bit and then let it go. that sort of worked the first way I configured it; with 1 8bit port expander and an inverter to keep the 'other side' of the relay always opposite of the single control bit for that relay. it had voltage surge issues that could be solved but I gave up and am now going to try 2 controllers; one bit for each side of the latching relay and no global enable 'line'. it also gives more control over each bit of timing.

another hint: port expanders and arduinos can put their pins in high-z mode, so you can EITHER keep both relay pins at the same potential (both bits 0 or both bits 1); OR you can do a combo of 01 or 10 to toggle them; then bring one of the lines into high-z (set it as pinMode(input)) and you break the circuit, leaving the relay in the desired state but not drawing any current at all.

for a better executed solution, you -may- need (or want) to opto-isolate. maybe.

or use ULN2003 style driver chips.
I think the H-Bridge is nice - since the number of components are small and easily available.

Regarding driving the relays I have to come up with an solution - since you do not want to waste too many pins - even with port expanders.
post #44 of 123
Interesting discussion on LDR's

I had not heard of those before.
I am definitely going to be looking into using one of these for any high profile amps I make down the road. Hopefully linuxworks will have that project in motion by then. If not, I might have to take it on.

Anyway, why would you be using an audrino to control it?
I really don't understand the appeal of the device.

Maybe microcontroller programming is harder than I understand... I've only done a slight bit of PIC programming... and didn't do anything useful.

I plan on designing an AVR based alarm clock as practice during this year. It seems like the perfect project to get you into the swing of using microcontrollers.
post #45 of 123
I played around with the 'basic stamps' as my semi-recent intro to microcontrollers. they were fun and well supported but expensive! I did a BS1 and BS2 program and then lost interest in that system (again, mostly due to cost).

if the arduino was not 'the thing' to use, I would be using PICs. I never got into PIC and went straight into arduino land. the tools seem nicer (C language as a standard, which I prefer anyway) and there was gcc support as well (for when I wanted to break out of the gui shell). lots of current hardware talk and lots of neat functionality that people prototyped *rapidly*. I was able to get useful things done in less than 1 week and that was due to having a lot of already-done examples that you simply had to integrate. its mostly about integration, really; and then some custom 'glue' code. but a lot of routines and frameworks are already out there and so its a rich library, overall.

arduino is also a bit more on the 'open source attitude'. I'm not aware of anyone selling arduinos that don't also include the source code, as well. that way you are in charge of your own system and you can over-ride any defaults you don't like. with the PIC culture, I don't quite see that, and 'locked down' chips seem to be the norm.
New Posts  All Forums:Forum Nav:
  Return Home
Head-Fi.org › Forums › Misc.-Category Forums › DIY (Do-It-Yourself) Discussions › Arduino based passive analogue input selection & volume control