Pages

Thursday 27 December 2018

IoT Audio Source Switcher [Part 1 - Hardware]

Problem In our kitchen we are currently unable to simply switch audio inputs, to select between the TV audio or Chromecast Audio for music playback.

Obvious Solution Buy an AV amp with multiple inputs and a remote.


My Solution Create a generic WiFi enabled audio switcher using an ESP8266 controlled by MQTT messages.


Why...?
Why go through this effort to make my own IoT audio switcher? Well, as always the first answer is because I can. But, talking strictly about tangible benefits to a custom solution over a bought one, these were my main driving factors;
- Lower Cost (minus my time)
- Better API (if any at all with a commercial product)
- No reliance on installing yet another app and granting access to my details
- No cloud - if my internet fails it'll still work
- It's a generic external device I can choose to pair with any future amp of my choice




Step 1: The Amp

At this proof-of-concept stage I didn't want to run the risk of frying my main home cinema amp so I went with a cheap stereo amp from Amazon LEPY LP 2024A+ Plus Amplifier. Honestly, it's really not that bad, driving my Monitor Audio Bronze 2 bookshelf speakers and it sounds great, obviously it's not very loud but enough for testing.


Step 2: Breadboard

The circuit is pretty simple, use a relay to switch audio sources. This is actually my preferred method over using solid state components. Any electrical connections shared with the audio path is just asking for trouble, every shared connection is a point of ingress for electrical noise that will corrupt the audio signal. The switcher isn't going to be selecting between input sources at any fast rates so the slow mechanical relays are absolutely fine.

I sketched out a rough circuit diagram (it has been about 15 years since doing any circuit diagrams so I expect there are mistakes), at least I knew roughly what I wanted to do.

Surface Pro is great for this sort of task (ok... so is a pen and paper but at least with the Surface it's already in picture format)

Once all the components arrived I set about prototyping on a breadboard. Always work in stages. There's no point in building up the whole board and discovering you've made a mistake. Create the smallest viable circuit that will perform the task, in this case it will control the relay allowing audio signals through or not. This may be pretty obvious that it would work, but I wanted to test if the making and breaking of the contacts in the relay would create cracks and pops on the audio line.

Baby steps. Does it work with 1 relay?

Success, audio output is nice and clean. If the relay does create any audio artefacts they are filtered out by the amp. 
Now to continue building up the circuit. Scaling it up to 4 stereo channels then checking it still works. Add a Node-MCU ESP8266 and some simple code to switch 4 outputs to test each relay and switching multiple active audio source.




Add some I/O. Check it still works.


Step 3: Strip-board / Veroboard

Now it's getting exciting. The design is valid and the prototype works. Time to step it up and migrate the breadboard components to a copper strip-board or veroboard. Taking my time to make sure I've copied is exactly and making best use of the copper tracks to minimise the number of wires I need to cut and strip.

Following proof of concept on breadboard move the circuit over to veroboard.

Even with careful planning the veroboard wasn't wide enough to fit the Wemos D1 mini, so I had to create a little daughter board for it to sit on.
Regardless of this mishap it's starting to look and sound pretty good.


Check it all still works.


Step 4: Features and Functions

Now it's time to add the finishing touches. Adding 3mm blue LEDs on flyouts means I can easily position them in the case. This indicates which source is the current active input.


Add indicator LEDs to show which output is active.




Check it all still works again.


Sometimes it's less convenient to pull out the phone, unlock it, open an app and switch the audio source. Just press a button on the wall.

The software side of this project will be outlined in part 2. I'll talk about the ESP8266 and MQTT.


Step 5: Assemble

Putting it back together I noticed the amp has a really cheap look to it with a bright blue light all round the clear plastic of the volume knob. This won't do.
I drilled a 1mm hole next to the power switch of the amp, desolderd the power LED and put it on a flyout wire so I could position it behind the new hole.


Drill a tiny 1mm hole.

The LED on its own is too bright.
Covering the hole and with masking tape attenuates the brightness just enough.


Much better.


Reassemble the amp.

After much searching for an aluminium enclosure I found it better value to just buy another amp, remove the internals and make custom face and back plates. Now I have nice consistent looking, stackable, units... and I now also have spare amp internals from the donor unit!

Top: Amp Front
Bottom: Switcher Front

Top: Switcher Rear
Bottom: Amp Rear


Step 6: Deploy

Fin.
The amp and switcher combo is now deployed in the kitchen and paired to some spare Creative speakers.
Connecting it up to the kitchen TV. Currently two inputs are used, TV and Chromecast Audio.


Summary

I built an IoT audio source switcher with 4 stereo inputs and 1 stereo output. This will be used to switch the input of an audio amp. Sources are switched using relays to avoid any cross-talk or other components leaking noise into the audio path.
I'm using an ESP8266 to control the unit and provide wifi access. Communication is handled using the MQTT protocol whereby clients can 'subscribe' and 'publish' messages to 'topics'.

The switcher subscribes to a topic e.g. "0/kitchen/av". Other devices can publish to this topic "0/kitchen/av" and include a message, this could be JSON encoded e.g. {"set": "source", "value": "2"}. Any device subscribed to this topic will receive this message and can process it accordingly.
I can publish to this topic from anything, an app, console, or another ESP8266. In one example I show a simple button press on another ESP8266 publishing a message to select the next source.

All the MQTT messages are handled by a local server or 'broker' running on a Raspberry Pi. The local nature of this 'IoT' means it doesn't rely on any external internet connections, third-party services or companies (https://www.telegraph.co.uk/technology/2018/10/12/glitch-yales-smart-security-system-sees-brits-locked-homes/)















No comments:

Post a Comment