Archive for the ‘Hardware’ Category

New Audio Ripping Box

Posted: June 16, 2018 in Storing, Hardware, Audio
Tags: , ,

So the old Vortexbox is no more, the Atom 330 is so 32 bit that very little decent software now works on it. More by luck than judgement I managed to find an old micro-ATX board that has now been roped into service.

Given the variable quality of the music library, I’m seriously considering re-ripping everything to FLAC to ensure the best quality on the various playback devices we have.

So the question is – do I install Vortexbox (and perhaps get around to trying Bliss as well) or do I look at alternatives?

Itinerant fiddler…. so alternatives it is!

So far I’m looking at 3 options: Daphile, Vortexbox and dbPowerAmp.

First up Daphile

Daphile is a Gentoo based distro that does basically the same as Vortexbox. It is much more locked down as there is no access to the underlying system, and there are no additional services that can be added to enhance the functionality. It rips CDs as FLACs and adds them to the onboard LMS server. It does support LMS plugins btw.

The UI is much more polished than VB, with very little effort I can configure it to rip to my unRAID server where our music is actually hosted. I can specify the quality of the FLAC, schedule backups of the local music folders and even access Jivelite to control local playback.

Metadata is added but only via a single source (I can’t remember I’ll add it later!) and has mis-identified a couple of CDs.

What it doesn’t do…. No DVD ripping, no Plex, Subsonic or Bliss servers. It doesn’t allow you to rip to FLAC and then automatically create mp3s as well.

Generally I like it, I’m in two minds about keeping it but I have a couple of issues.

  • The inability to also create mp3 files from the same source at the same time
  • Metadata quality
  • Inability to configure naming convention for the output

If I’m just re-ripping for FLAC, then it will do the job very well, but I’ll still need to do manual work to rename and check the metadata. As there are several hundred CDs, that’s not great.

Next up Vortexbox.


I know, I got distracted again…. New versions of OpenHAB2, so trying to do a new clean build of my house automation – getting rid of all those items I’ve started to add and then never got around to removing afterwards.

I’m starting to look at ways to actually build this mishmash of ideas in the real world rather than on a breadboard. Although I bought some plain protoboards, it suddenly dawned on me that I had actually no idea how I would physically build this!

First question – how do I distribute the GND and 3.3V lines? In a breadboard there are rails along each side, but in a protoboard there’s no such thing. After some minor panic I eventually found something called a permaboard that basically resembles a breadboard, but allows you to solder on to it.

Next question – how do I connect the Pi GPIO pins to the permaboard? I’m guessing that I can get some kind of cobbler to connect the GPIO pins via a ribbon cable to the cobbler soldered on to the permaboard, but I don’t need all the pins and I’d rather just have the pins I need exposed on the permaboard. It also means that the permaboard could be smaller.

My initial idea is to use a 40-pin ribbon cable with a fixed connector for the GPIO and individual female connectors at the other end (see here). If I solder sets of breakout pins to the permaboard, I can connect the female ribbon ends to the board that I need and leave the other ones hanging around. As the connectors are female, the chance of them shorting out something if the flop around is much, much less!

I’ll try and find some time and report back.

Audio Ripper

Posted: March 2, 2018 in Audio, Hardware
Tags: ,

So the Vortexbox ripper is on its last last legs, doesn’t update anymore and I’m finding that the metadata matching is occasionally ‘off’.

Looking around it looks like XLD on the Mac is my best option for ripping new stuff, I like the look of dbPowerAmp (used to use it years ago), but I’m not sure that I need to buy software.

Bliss is looking like a good choice to try and fix the issue in the library, I must try it out properly.

Xiaomi Smart Home

Posted: January 6, 2018 in HA, Hardware
Tags: ,

The OpenHAB community have been taking about Xiaomi and the raft of components that you can get relatively cheaply (even cheaper direct from China!). It’s ZigBee based, so it shouldn’t interfere with current devices.

I’m not keen on the idea of adding another hub/gateway to my setup, but for roughly £20, it might be worth a punt. I always tell myself that “worse case I can sell it on eBay”. Never actually happens though…. So AliExpress and GearBest both list the gateway, but the one on GearBest appears to be the 3rd generation. From reading the notes on the OpenHAB documents and forums it seems that gen 2 or later is supported. AliExpress may have the gen 2 and gen 3, but as all the suppliers use the same stock photo, it’s quite difficult to see. Being Christmas, there’s a sale on, so I’ve also picked up a button and 2 door sensors. Total cost ~ £30 with shipping.

Let’s be honest I couldn’t get 2 Z-Wave door sensors in the UK for that price!

The downside to all this is the time for delivery. I ordered the kit on 21st December and it finally arrived on 4th January. Not long really given the Xmas holidays, but I get impatient waiting for new toys!


When the parcel finally arrived, it contained 4 small white boxes. The largest – probably 10cm a side contained the new hub.


Xiaomi Smart Hub with UK Adapter

The other 3 were the same size, each containing a device.

Each box also contained a small instruction leaflet in Chinese, and if appropriate some spare double-sided tape to mount the device.

The Hub includes a LED ring for light effects, an ambient light sensor as well as a speaker. The idea is to plug it into the wall socket somewhere central and use these features as part of the whole home solution.


The installation of the hub and devices is a little ’round-the-houses’, but is outlined in the OH documentation here.

Slightly disconcerting is the female Chinese voice bellowing out of the hub when you try to add devices. Once you jumped through the hoops of adding the hub to OpenHAB, any new devices appear in the Inbox for inclusion. As per the binding documents, I’ve blocked the hub from any external access. It means I can’t use the app, but I don’t need it as OH handles it all for me.

Using in OH

One of the things that took me a while to figure out was the alarm timer channel for the door sensor.

Number DoorSwitch_AlarmTimer <clock> { channel="mihome:sensor_magnet:<ID>:isOpenAlarmTimer" }

This value needs to be set on the hub by OH and determines how long the door should be in an OPEN state before the ‘isOpenAlarm’ switch to be triggered. I believe it’s currently defaults to 300 seconds, but I recommend experimenting.

In my rules I set the value on system startup

or in the newer format
So the alarm will trigger if the door is open for more than 120 seconds.
I’m happy with the kit so far, but finding somewhere to put the hub is an issue – it only comes with an integrated plug for use in China, so a China -> UK adapter is needed, which adds to the height of the device. With an adapter it is now about 15cm high, so far too big to just plug into the wall!

Next Steps

I’ve got a couple of Z-Wave Fibaro motion detectors that also supply temperature and humidity info that go through batteries at an incredible rate. To be honest, the temperature and humidity data is more important that the motion sensor, so I’ve ordered a couple of temp & humidity sensors to replace them as well as 2 more buttons.


FYI – These devices are NOT always CE certified for use in the UK, so using them is at your own risk.



So I’ve gone through two use cases so far, and I have successfully got these working using the basic plug and play parts of an introduction to electronics kit. No soldering, just pushing pins into the prototyping board. The next couple of use cases I think I’ve figured out, but as the cheap electronics are coming from eBay via China, I’m still waiting for the parts to arrive before I actually try these ones….

So this is (at time of writing) all theory!

Use Case 3 – Volume Control

While the X400 has an on-board volume dial, I’m not convinced that I can build a suitable mechanical coupling to allow me to expose this outside of the enclosure. My gut reaction is to use this as the max level control and then use software to control the volume up to this hard limit. Volumio will then treat this as the 100 (max) point in its volume scale and allow users to set volumes. Volumio can also set the mute the same way, but how do I control the volume?

I believe that I can control the volume via the software mixer in Volumio. Like with mpc, I should be able to issue a command to increase or decrease the volume. As with my previous two use cases, adding a switch to the GPIO and detecting it appears to solve this problem.

Adding another set of switches seems ‘wrong’…. So perhaps I should try something a little bit more complex and user friendly? Maybe using a rotary encoder (a dial!) instead to control the volume? Maybe I should be really smart and try a rotary encoder with a push button (a dial you can click) to allow for mute as well?


Rotary Encoder – NO Switch

Python Code:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
from RPi.GPIO import GPIO
from time import sleep

#Define GPIO Pins that have buttons
clk = 5            #volume dial clk
dt = 6             #volume dial dt

GPIO.setup(clk, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
GPIO.setup(dt, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

volume = 0
clkLastState = GPIO.input(clk)

def changeVol(newVolume):
    print ("New volume is " + newVolume)

    while 1:
        clkState = GPIO.input(clk)
        dtState = GPIO.input(dt)
        if clkState != clkLastState:
            if dtState != clkState:
                volume += 1
                volume -= 1
        clkLastState = clkState

Update: The encoder I have has 5 pins, not 3…. clk/dt/GND/3.3V/something…. and that is represented in the code above. It still doesn’t have a ‘switch’.

Update: The latest version of Volumio has its own command line client that allows for volume setting.

volumio volume <value>

Use Case 4 – Radio Stations

The final use case is the ability to switch to live radio streams – something that is a must in a kitchen radio! I think we’re back to simple GPIO buttons on this one, with each one triggering a predefined playlist of a single stream. How we trigger the actual stream is something I’ve yet to figure out.


Radio Preset 1, 2 & 3

Still working on this bit…. #sigh


Use Case 5 – Modes

OK, so I lied. While playing with the HiFiPi I realised that the music is playing out of both the speakers and the headphone socket. As it was late and I didn’t want to wake the kids I needed someway to turn the speakers off. The X400 comes with 3 jumpers that are used to turn the amp on & off, the headphones on & off and mute all the outputs. Trouble is moving these around once inside the enclosure will be impossible.


X400 Output Jumpers

As these are fixed jumpers, it should be possible to use locking switches to fix the state in either open or closed, thus enabling the device component. A quick email to Suptronics support revels that this is true, so I now need to add locking switches to the shopping list to test.

This will mean I can add a mute button without using up a GPIO or adding code. The other two modes – headphones & speakers are more useful to me using the setup in the study at night. That way I can turn off the speakers and just use the headphones to stop me from waking the kids.

Parts List (so far):

Wire – whatever is appropriate to you setting!

2x 1 row pin headers

Momentary contact switch x1 – for ON

Momentary contact switch x1 – for OFF

Momentary contact switch x4 – Media shuttle commands

1x Rotary encoder

Momentary contact switch x3 – Radio preset buttons

Locking switches x3 – Mode output control

So now the real learning starts. I need to decide what I want the box to do, how to do it and then build it. Easy huh? The code that I reference here is also in my GitHub repo, it’s likely that these snippets get superseded as I figure out how the stuff works. I’m also using the excellent Fritzing to figure stuff out with the wiring, so it may pay to look at that as well if you want to design your own parts.

The other thing to note is that my switch circuits run from the GPIO Pin to GND – making the Pins use the PULL UP resistor in the Python code. If I had run the switches from Pin to 3.3V, PULL DOWN resistors would need to be declared.

As we are access the GPIO, all the python code will need to be run under sudo to gain access.

Use Case 1 – We must be able to turn the player On and Off via a switch

OK so after a lot of Googling it becomes apparent that all the normal method to deal with this – add on boards with switches – are inappropriate because of the X400. As the X400 provides power to the Pi, none of the aftermarket solutions will work.

Use Case 1 (Amended) – We must be able to turn the player On and Off

The answer (in theory) is to use the ‘reset’ switch header as an ON and to add a switch to the GPIO with some code to handle the OFF part.

There is a P6 header on the RPi boards that allows you to reset the device when it is shorted. While absolutely not suitable for a clean shutdown, it will restart the box if it is in a powered but shutdown state. The issue is that this header isn’t populated, so we will need to add some pins prior to connecting a switch of some kind. This means soldering the pin header to the board itself (gulp) and then connecting the new header pins to a switch. So that’s the ON part sorted.

For OFF, connecting a momentary switch to one of the GPIO Pins and then detecting it with some Python to trigger the appropriate shutdown command appears to be the easiest and safest method. This protects the SD card and ensures that everything is clean before shutting down. As power is still applied, we can use the new ON switch to restart when required.

Simple shutdown switch
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# Assumes switch is connected to GND - so uses PULL UP

import subprocess
import time
import os
import RPi.GPIO as GPIO


button = 20

GPIO.setup(button, GPIO.IN, GPIO.PUD_UP)

while True:
 button_state = GPIO.input(button)
 if button_state == GPIO.HIGH:
  print ("Shutdown")
 #os.system("sudo shutdown -h now") # Send shutdown command to os

Use Case 2 – Play, Pause, Next, Previous & Stop

So after some more Googling it seems that I can use the MPC client (the Music Player Daemon command line bit) to control playback from the command line. As Volumio includes this part, simply issuing commands allows us to control things via the terminal.

 mpc play

mpc pause

mpc stop

Issuing just


Will return a list of commands you can use.

So we’re back to the GPIO with an additional 5 4 momentary switches, each of which then uses Python to issue the appropriate mpc command.

** UPDATE **

Oops. While working on building the device modes (see Part 5), I realised that GPIO Pin 17 (Board Pin11) is already claimed by the IR receiver on the X400. This means that I have now lost my ‘play’ button. The solution is to remove GPIO 17 from the code and change the GPIO 27 (Board Pin13) from

mpc pause


mpc toggle

Which, unsurprisingly, toggles play/pause. The other advantage is 1 less button to fit somewhere on the final case!


Play/Pause, Stop, Previous & Next

Python Code:

# -*- coding: utf-8 -*-
# Assumes switch is connected to GND - so uses PULL UP

import os
import subprocess
import time
import RPi.GPIO as GPIO


#Define GPIO Pins that have buttons
play_pause = 27 #Play/pause mpc toggle
stop = 22 #mpc stop
prev_track = 18 #mpc prev
next_track = 23 #mpc next

power_off = 20 # sudo halt now

#Configure PULL Up and pin connections
GPIO.setup(play_pause, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(stop, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(prev_track, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(next_track, GPIO.IN, GPIO.PUD_UP)
GPIO.setup(power_off, GPIO.IN, GPIO.PUD_UP)

#Begin loop to wait for button press
while True:
 if GPIO.input(play_pause) == GPIO.LOW:
  print ("Play/Pause")['mpc', 'toggle' ])
 elif GPIO.input(stop) == GPIO.LOW:
  print ("Stop")['mpc', 'stop' ])
 elif GPIO.input(prev_track) == GPIO.LOW:
  print ("Previous")['mpc', 'prev' ])
 elif GPIO.input(next_track) == GPIO.LOW:
  print ("Next")['mpc', 'next' ])
 elif GPIO.input(power_off) == GPIO.LOW:
  print ("Shutdown")
  #os.system("sudo shutdown -h now") # Send shutdown command to os
  #print ("Nothing")

Parts List (so far):

Wire – whatever is appropriate to you setting!

2x 1 row pin headers

Momentary contact switch x1 – for ON

Momentary contact switch x1 – for OFF

Momentary contact switch x54 – Media shuttle commands

Links & Refs:


Reset Switch –

In the previous two parts I’ve looked at building something a little more capable for audio playback. What I’ve built works brilliantly with headphones, but isn’t in any way  suitable for use by ‘normal’ people and definitely not with small children around.

So I decided to look at following the herd and try to build the new music player in an old enclosure. After much eBay hunting, I found several nice radios that could be refactored. My issue with them was the size.

If I want to build a stereo radio I need 2 speakers (obvious huh?), but most of these radios are mono, so adding a second speaker either means running two tiny speakers or modifying the case to allow for a second speaker. Either way two speakers take up space and the X400 is already considerably bigger than the HiFiBerry or equivalent board.

If I go the whole hog and try to include some form of interface/screen then a repurposed radio chassis is completely unsuitable. I can try and find a large (think valve type) radio from before the modern radio. These are generally quite large but come with wooden cases that can make the end product look gorgeous. This scenario gives me the opposite problem. The end product would be far too big to sit in the kitchen, it would be more appropriate for the dining room or somewhere as a centre-piece.

The X400 is rated to drive 2x 20W speakers, I had originally planned to buy some car speakers from eBay once I had the rough dimensions of the enclosure I wanted them to go into. So everything really hung off of finding a decent box to put it in.

Being a total novice at this stuff, I decided that it makes more sense to try and build something, learning as I go. I’d have to be prepared to completely get it wrong, throw away stuff and to start again. Once I’d figured things out, maybe then I could build the ‘final’ version.

With this in mind I decided I would get a broken Roberts Colourstream internet radio. While big and modern, it has a couple of decent speakers and a touch screen that I hoped I could re-use. The case should be big enough to fit everything inside and it is already configured for stereo.


Roberts Colourstream Internet DAB Radio

The previous owner had attempted to ‘fix’ the device – resulting in the guts basically being supplied in a separate bag, but that was just one less thing for me to do. Removing the facia allowed me to get to the speakers and after a couple of minutes work  I had stripped the plugs off the speakers and had wired them directly into the X400. A boot of the Pi and suddenly we have music from the speakers.

The next part is figuring out what I want to do, how to do it and what parts are needed!