Monday 12 March 2018

Wedding Sign



I was asked to create a sign for a wedding. They're planning on having Karaoke and wanted a sign pointing to the bar for "Dutch courage".

Design


After exchanging a few ideas and a couple of preliminary sketches, we arrived at this design. Most of the graphics came from clipart, and the typeface is "URW Chancery L" in 132pt.


The overall size is  approximately a the size of an A3 piece of paper. As I don't have an A3 printer, I split the design across a few A4 sheets for printing.

Then came several hours of carving out the letters and patterns with a scalpel to create the stencil for later spray painting.









Building the sign
The sign is created from joining 3 lengths of up-cycled pallet wood. As with the Treasure Chest, the jointing was done manually with a combination of hand planing and simply finding lengths of wood that lined up well together.

The supports at the back of the sign for the stand
The wood is glued together, and also there are cross beams on the back - one at the top and one at the bottom.

These also form the mount for the stand.








The wood for the stand same from an old garden parasol that I upcycled. As it's previous life was as an object that hinged at various points and was designed to be folded, it was ideally sized - all I needed was to cut down the lengths. The pivot is nothing fancy, just a single screw.



The entire sign was sanded, and stained with a teak wood stain. An early attempt at stencilling the sign didn't go well, so the front ended up being sanded and stained a second time.
This turned out to be a blessing in disguise as after the second coat the woodgrain was much more pronounced and looked much better for it.

The arrow
Maybe I'm just a cynic, but it crossed my mind that although the venue and location has already been set for the wedding, Murphy's Law suggests that when the wedding rolls round, things will have changed and the arrow will end up pointing the wrong way, so I came up with the idea of making it a magnetic stick-on arrow so it could be swapped around.

The rear of the arrow with metal strip
Magnets embedded into the surface of the sign for mounting the arrow

I cut the arrow on the bandsaw, and painted it white, then a cut a section of flat steel and epoxyed it to the back of the arrow.
Then in the place on the sign where the arrow was to be mounted, I used a forstner drill to drill 3 inlays. In each of these holes I epoxyed a circular magnet so that it sat flush with the face of the sign.


Painting
I taped the stencil to the face of the sign, and applied two coats of enamel white spray paint. Unfortunately the delicate patterns on the edge of the stencil didn't work too well with the spray, so once a couple of sprays were down to mark out the position of the design, I removed the stencil and started painting by hand. To do this I sprayed some of the paint into the cap, and used a thin brush.

The end result

A post shared by Anthony (@darkmidnight_diy) on

Sunday 25 February 2018

PC case notification screen, part 3 - software & installation

In the first two parts of this project, I setup a Raspberry Pi to display notifications from my desktop PCs to a small LCD which I then 3D printed mounts for to install it into the PC itself.

Software
I originally hoped to use existing software, such as Grafana and Graphite, but although they do run on the Raspberry Pi, it was difficult to get them to behave reliably, so I ended up going for a homebrew solution.

As I alluded to in an earlier post, the data comes out of the desktop by piping output from the linux command sensors via the a USB serial port like so:

sensors > /dev/ttyUSB0 2>/dev/null

The application running on the Pi reads data from the serial port, and using a simple parser, extracts the system temperature.

This is then passed to a Processing.org sketch, which draws an (admittedly rather basic) gauge, displaying the temperature.

The code is available on Github. It also contains an interface class and an example implementation of that class, this is a wrapper I made around the Processing.org library to make it easier to compartmentalise the processing functionality into separate classes, with the intent of making it easier to create a modular display (so further notification modules could be added in future - system speed, email/social media notifications etc).

Installation

The two mounts are either side of the metal front panel of the case, back-to-back.
The Pi sits on the inside, and the display sits on the outside (of the metal chassis - it is covered by the actual front panel of the case).
This allows the outside of the case to remain unchanged, but the display of the LCD is bright enough to shine through the translucent panel.

When the PC is powered down, the USB port still provides power, so the Pi stays on, but the power to the display is cut. This avoids having to go through the Pi boot sequence each time, but allows the display to be shut off.


A post shared by Anthony (@darkmidnight_diy) on

Thursday 22 February 2018

PC-case notification screen: Part 2, mounts and wiring

In the last post, I configured a Raspberry Pi to receive stats from my desktop PC and display them on a small LCD from a car reversing camera kit.

The next stage is to turn this into a much neater setup to integrate it into my desktop PCs case.

Mounting
The Raspberry Pi quite a popular format, so there's plenty of cases on Thingiverse to choose from - no need to reinvent the wheel. I went with this tray design, as it was the easiest to adapt.

The front of my PC case has several mounting points for an array of fans, so all that was necessary was to create a way of joining the Pi Tray to them.
A simple 'X' shaped bracket in OpenSCAD is all that was needed. It would be easy enough to join this to the model for the Pi Tray, but I ended up printing them separately and gluing them together.




I used the same design as the basis of the mount for the display.
Out of the box it has it's own small stand to attach to a dashboard, with a screw pivot for tilting the display. My idea was to simply remove the stand part and use the same mounting point.





The Pi attached to it's completed mount

The mount for the screen. As you can see, it makes use of the existing stand mounts


Wiring

Note: The 12V line is typically the yellow line,
it just so happens on the connector I found was non-standard.

The LCD runs of 12 volts. This is nice and easy to deal with - Molex connector straight to the power supply. This was just a case of joining the connector for the display to the Molex.


The Pi requires 5 volts, and there's 2 options on how to provide this - Also on the Molex, or via USB. There's pros and cons to both methods.
  • Going the Molex route is more straightforward - it can use the same connector as the LCD, so wiring will be neater, but on the downside, when the desktop is powered off, the power to the Pi will be cut. This runs the risk of corruption of the SD card.
  • Going the USB route means more wiring and a separate power lead, but has the advantage that my desktops motherboard still powers USB devices when powered down, therefore the Pi can remain on.
I opted to go for the USB option. There's spare USB headers on the motherboard, so I needed to make an adapter to use those.


Starting with a short USB extension cable, I removed the socket and split out the wires.


Then using a header lead pulled from an old PCs front panel, remove the header connector. Then it's just a case of matching up the pins and joining them together.


The adapter without the 3D printed cover (top),
and the finished adapter (bottom).
Each motherboard adapter can support 2 ports, so I left the remaining wires outside (just heat-shrinked for safety), so they're available if I decide to add another internal port later.

The Pi is connected to this using a console cable. This is a USB cable with 4 output pins - 5V, ground, TX and RX, and connects directly to the GPIO of the Pi.

It's not recommended to use the 5V GPIO pin for power as it lacks some of the control circuitry that the usual power socket has, but has the power is coming from a regulated USB socket, it should be fine in this case.

The console cable also takes care of the level conversion of the 5v levels to Pi-safe 3.3v, and appears to the PC as a USB-serial adapter.

Finally, all that's left is to connect the display to the Raspberry Pi. Both the display and the Pi have Composite sockets, so I removed the socket from the display and replaced it with a plug.

SCAD code for the mount
As this is really quite a niche thing I'm not going to put the files on Thingiverse, but here's the OpenSCAD code in case it's useful to anyone.

// Just comment out the one you don't want
piMount();
screenMount();

// Couldn't be bothered to do the conversion...
function inches(x=1) = x*25.4;

module piMount() {
  difference() {
    cube([inches(4.5),inches(2.75),inches(0.125)], center=true);
    translate([inches(-2.0625),inches(-1.125),0]) { screwholes();}    
    translate([55,0,0]) {cylinder(inches(0.75),inches(0.8),inches(0.8), center=true);}    
    translate([-55,0,0]) {cylinder(inches(0.75),inches(0.8),inches(0.8), center=true);}
    translate([0,40,0]) {cylinder(inches(0.75),inches(1),inches(1), center=true);}
    translate([0,-40,0]) {cylinder(inches(0.75),inches(1),inches(1), center=true);}
  }
}

module screenMount() {
  difference() {
    cube([inches(4.5),inches(2.75),inches(0.5)], center=true);
    translate([inches(-2.0625),inches(-1.125),0]) { screwholes();}    
    
    cube([1.125*25.4,12.7,50], center=true);
    rotate([0,90,0]) {cylinder(5*25.4,0.125*25.4,0.125*25.4,true);}

    translate([55,0,0]) {cylinder(inches(0.75),inches(0.8),inches(0.8), center=true);}    
    translate([-55,0,0]) {cylinder(inches(0.75),inches(0.8),inches(0.8), center=true);}
    translate([0,40,0]) {cylinder(inches(0.75),inches(1),inches(1), center=true);}
    translate([0,-40,0]) {cylinder(inches(0.75),inches(1),inches(1), center=true);}
  }
}

module screwholes() {
  cylinder(inches(5),inches(0.125),inches(0.125),true);
  translate([inches(4.125),0,0]) {cylinder(inches(5),inches(0.125),inches(0.125),true);}
  translate([0,inches(2.25),0]) {cylinder(inches(5),inches(0.125),inches(0.125),true);}
  translate([inches(4.125),inches(2.25),0]) {cylinder(inches(5),inches(0.125),inches(0.125),true);}
}

The basic wrapper around the USB connector
difference() {
    cube([15,40,9], true);
    translate([0,7,0]) {cube([13,27,7], true);}
    cube([9,45,7], true);
    translate([0,0,5]) {cube([20,50,10], true);}
}

Wednesday 7 February 2018

PC case notification screen

I've mentioned before how my interest in electronics spawned from PC modding.

Now that I've built a new desktop for the first time in a while, I've been keen to return to PC modding and come up with some projects for my new machine.

Thing is, these days PCs are designed much more aesthetically than the old beige boxes, and so there's a lot less that needs doing - the case I have has a large glass window, the motherboard already has some RGB LEDs built in - the graphics card even has some too.

I wanted to add some case lights - thought that might be a nice throwback project, but I noticed the motherboard already has pin headers for a 5050 LED strip. Don't get me wrong, I think it's a good thing that manufacturers are taking the initiative, but all it involved was little more than soldering some wires to a length of LED strip and plugging it in - hardly a project worth writing about.

So I thought about doing a new take on the case-front notification screen. In the past this would be a basic HD44780-type LCD that could display basic text - currently playing track, system temperature etc.
My plan is to use a small, full colour screen to fit with the more colourful style of the new desktop.

Other requirements are that as I dual boot Windows and Linux, it needs to work in both environments, so I'm aiming for minimal overhead on the computer itself.

Setting up the Raspberry Pi

In order to meet that goal, I plan for it to be a completely separate device that the PC can just pipe data to, and the device itself handle the processing and display. I started with a Raspberry Pi A and a clean install of Raspbian ("Stretch Lite"), and booted to the terminal using the serial console GPIO pins.

Getting connected & installing Java
I'll need to get the Pi connected to the internet temporarily to get everything setup and installed. I used a USB wifi adapter then edited

/etc/network/interfaces
 
with the following, replacing the ssid and password as necessary.

auto lo iface lo inet loopback iface eth0 inet dhcp allow-hotplug wlan0 auto wlan0 iface wlan0 inet dhcp wpa-ssid "ssid" wpa-psk "password"

then of course started with the usual update/upgrade

sudo apt-get update sudo apt-get upgrade sudo apt-get install openjdk-8-jdk
 
and reboot if necessary.

The display
As the display is to be mounted in a desktop computer case, there are some rather specific requirements.
  • Size - it needs to be small enough to fit in the case
  • Power - it can't use too much, and needs to be able to be powered from the computers PSU
  • Connectivity - HDMI would probably be overkill, after all, it's for system stats and notifications, not a extra monitor, and it needs to connect to the Pi, so Composite video seems appropriate.

The display and its connections
After examining and ruling out various options - netbook screen, digital photo frame, etc. I came across some reversing camera kits on eBay. For a fairly reasonable price, these kits contain a small camera for the rear of the car, and a small display to view the video on.

It fits the bill nicely - small, composite video connection, and runs of 12v, which can be provided by the PSU. Perfect. The camera the kit includes is unnecessary for this project, but I'm sure I'll find a use for it someday.



Adding a GUI
The Raspbian 'Lite' distribution doesn't come with a GUI, so I needed to install one - I went with RPD.
This is installed with

apt-get install xserver-xorg xinit raspberrypi-ui-mods lxterminal gvfs
 
As the pi will be running without user interaction, it needs to be configured to automatically login to the desktop. This can be done with:

raspi-config
 
We also need it to stop going to screensaver. The easiest way to do this is to just uninstall the screensaver with apt-get remove xscreensaver.
We also need to stop the screen blanking, this can be done by adding the following lines to /home/pi/.config/lxsession/LXDE-pi/autostart
 
@xset s noblank 
@xset s off 
@xset -dpms
 
And finally we need to hide the mouse cursor:

apt-get install unclutter
 
Once installed, we need to add the line unclutter -idle 0 & to /etc/profile.
 
Setting up serial communication
The Pi will be without internet connection, so to get data from the PC to it, we'll be sending it over the GPIO pins.

Firstly, use raspi-config again to disable the serial port console, as this can interfere with the data transfer.

Then run
sudo stty -F /dev/ttyAMA0 speed 115200 cs8 -cstopb -parenb to setup the serial port.

Run the same command on the desktop - just change the /dev/ttyAMA0 part to whatever the serial port on the machine is - most likely /dev/ttyUSB0 if you're using a USB to serial adapter or Arduino. (Currently I'm using an Arduino with a 5v to 3.3v level converter, though will come up with a more permanent solution when installing the screen in the case).

Installing the software
Take the compiled jar and move it over to the Pi - I put it in /home/pi.
Create a file in /home/pi/runPi.sh containing this command

cat /dev/ttyAMA0 | java -jar /home/pi/PiScreen.jar

Edit the /etc/profile and add this command to the bottom

sh /home/pi/runPi.sh &
 
This will cause the software to run on boot, and pipe input to the serial port to the application. That's it for the Pi setup.

Setting up the desktop
The software is designed to take its input from the 'sensors' command which is part of the lx_sensors package, so install this if it's not already installed on your system.

To test the display, with it booted and running, on the desktop send the comman

  sensors > /dev/ttyUSB0

you should see the dial on the display change to show the system temperature.
Send it a couple of times with the system under different loads to see the number change.

To automate this, simply add it to cron to run at set intervals, of if you want it run more frequently, add the below to ~/.bashrc (the 5 indicates 5 second intervals, adjust as necessary)

startSensors() { while true ; do sensors > /dev/ttyUSB0 2>/dev/null & sleep 5; done } 

This will allow the sensors to be started by using the command "startSensors &" in a terminal.

The next steps will be tidying up the wiring, and mounting it in the case itself.




The UI is quite basic at the moment, but I intend to expand on it to include other stats and publish the source so that others can add their own widgets to the display.

Wednesday 17 January 2018

App Update: Bluetooth Macro and Voice Input v2.1

A new version of the Bluetooth Macro app is available on Google Play


As much as I like gaming, one thing that irritates me is "Quick Time Event" button mashing game mechanism which requires the player to repeatedly bash a button usually in response to a cinematic event, for example:

Interrogation Scene - Metal Gear Solid

As protagonist Snake is interrogated, the player is required to mash a button to resist the electrocution.

Pooping - South Park: The Stick of Truth


A more immature example is mashing a button to poop.. it is South Park, after all.


So I've updated the Bluetooth Macro app to include a 'button mash' function.


Usage
The new functionality can be found by swiping left past the voice recognition section screen.

Enter the keys to send in the text-to-send box, and use the slider to set the frequency (The minimum is 1/sec, max 100/sec).

Note that while the app strives to keep these times as accurate as possible, there will be some limitations based on the hardware that you use.

Click start to begin 'mashing' the button - it will continue until you click stop.

Randomising time
A lot of third party game controllers can include a rapid-fire button that the player can simply hold down. Some games (such as MGS) could detect these (presumably because such a solution would send button presses at a predictable set interval, whereas a human player would have marginal inconsistencies in the spacing of the button presses.)

The randomise checkbox aims to overcome this by introducing a small variation between the keypress delays.


Support/Feedback
Unfortunately I'm not in a position to offer any kind of official support for this, so use entirely at your own risk. If you have any trouble with it, then feel free to get in touch, and I'll try to help as and when I can, but I make no guarantees!

Thursday 28 December 2017

ID-card Lanyard Headphones

I, like a lot of people, work in an organisation that uses access control cards that we need to carry at all times - usually on a lanyard around our neck. I also like to listen to podcasts and music while I work, so that often means having a pair of earphones around my neck too. The combination of the two often results in tangling and general annoyance, so I thought I could combine them.

I revisited the cable tidy that I previously created (it was one of the first 3D printed objects I created, and definitely in need of some improvement).
I've since moved away from OpenSCAD in favour of Blender as my 3D skills have improved - The new design can be found on Thingiverse.

The plan is use a scaled down version of the cable tidy to control the part of the earphone wire from the connector to the split


and then have each earphone attached to the lanyard, coming out at the top with enough slack to reach my ears.

The cable tidy is straightforward enough, there are three pieces - the two halves of the inner section, and the outer ring. They all friction fit - once printed, just lightly sand necessary edges until a snug fit can be achieved.


A post shared by Anthony (@darkmidnight_diy) on

To create the lanyard I started with two promotional ones I'd received (they tend to be a common hand-out at conferences and trade shows). The main one also has a side-release buckle just up from the dog clip (the clip that holds the card... yes, I had to Google what it was actually called), which would also solve another annoyance - having to remove the lanyard while driving to get through the car park security gate.

The second, sacrificial, lanyard, is slightly narrower. This lanyard was cut into strips which would be stitched to the main lanyard to create a channel to contain the earphone wire.

I stitched up one side, put the earphone wire in place, then stitched down the other side to lock it in place. The length of wire was too long to begin with - this was partially by design - I didn't want to leave the top (earphone side) just open, as I could forsee wear and tear putting too much strain on the stitching. What I did instead was stich it 'too high', then cut down the middle of the sacrificial lanyard to pull the earphone through and create enough slack, and then stitch up behind it, so that there was more, stronger stitching supporting it.

I repeated this exercise for the other earphone, and it was done. One snag was that the earphones had a small button halfway down the wire for the right-hand earphone, which was a little too big. A dab of contact cement held this in place, and unless looking closely, it's not noticeable.

I tested using the lanyard at work before the Christmas break. As with all wearable tech, there's always the concern that it looks too goofy, so I picked a day where the office wasn't too busy, to see what, if any comments were made. All the feedback I heard was positive - for the most part it just looks like I have the headphones resting around my neck, and as for the cable tidy, a lot of others have keys and other items hanging from their lanyards, so it doesn't seem too out of place.


Saturday 2 December 2017

Dual booting Fedora 27 and Windows 10

I recently built a new desktop PC.
My previous machine has been in use for nearly a decade, so it seemed like time, and I've been wanting to experiment with watercooled systems.
I wasn't planning on making a post of it, but there were a couple of unexpected issues I ran into that I felt were worth documenting for future reference.

Dual Booting

I usually dual-boot Fedora Linux and Windows.

Unfortunately this time round, that was not as straightforward as usual.
After quite some time of searching, I found the answers, but it was a lot more hassle than it should've been, so I'm writing up my experience here in the hope that it may help others who are trying to achieve a similar setup.
The TL;DR of the problem is that it only ever seemed to be able to find the Windows boot loader, or the Fedora one (When I've done this in the past, it would find the GRUB loader, which would detect the windows one and add it as an option in the boot list, but this time it was not detecting the windows loader.)

There were quite a few failed attempts, so I'm not including an entire history, but this is the setup that worked.

Firstly, I used parted from a Fedora live disk to format the SSD into 2 partitions (a 50-50 split), one ntfs partition, one ext4.
Then I rebooted and installed Windows 10 to the ntfs partition. The installer actually complained about a lack of space, so to fix that I ended up removing the ntfs partion and letting Windows create it's own in the free space (it ended up using it's 50% of the drive to create multiple partitions.).
Another reboot to Fedora 27 live, and worked through the anaconda installer, specifying that it use it's ext4 half of the drive. Again, it wanted to use that space to repartition in it's own way, which is fine.
The bit that appears to really matter is to ensure that Fedora creates a /boot/efi partition in the same place that Windows creates it's /boot/efi partition (see screenshot)

The "Unknown" partitions at the bottom are the ones created by the Windows installation.
The /boot/efi partition is sdb4, as is the Fedora-created one (highlighted).


I was concerned about them being the same partition and whether or not Fedora would overwrite what was already there, so I created a backup image of that partition onto the other storage disk in that machine before proceeding with the installation.
Then began the install.

Once complete, I rebooted, and the GRUB menu appeared, with the Windows option available.

Networking Issues

The motherboard that I have chosen is the ASUS Strix Z270F.
It has onboard ethernet, which worked absolutely fine out of the box on Fedora, but on the clean Windows 10 install, the LAN controller was not detected.
Again, there's lots of forum posts with people suggesting various solutions, none of which seemed to work for me.

For some reason, installing the LAN driver direct from the ASUS-supplied driver disc didn't work - it failed because it couldn't detect the hardware.
Even opening up the disk, navigating to the LAN folder and running the Intel setup application from there didn't work.

The only way I found it would work is opening up "This PC", going to properties, then Device Manager, and finding the hardware there (it will be under "Other devices" and have a yellow "!" marker to show it's not working)
Right-click on it and select Update Driver Software.
Then "Browse my computer for driver software", and navigate to the driver disk's LAN folder.
Windows then detects and installs it and it works fine.

I can't begin to guess why installing it that way works and the other ways don't, especially as it's the same driver, but whatever. It's fixed.


Spec

MotherboardASUS Strix Z270F
ProcessorIntel i7 Kaby Lake 4.2Ghz
RAM32GB DDR4 3200MHz Corsair Vengence LPX
Disks500GB SSD, 4TB HDD
GPUGigabyte GTX 1050 Ti 4GB
CoolingCorsair H55
OSFedora 27 & Windows 10 Dual Boot