For the most part, the patio plan came together well, but we had use more slabs from the shed side for the base layer than we thought, because the greenhouse itself was cemented into the ground by metal supports, and not sat on a slab base as initially thought.
This in turn meant we were two slabs shy of what we needed, but we were able to source some that were close enough in appearance.
When it came to placing the concrete blocks, we realised we could use fewer than estimated by spacing them out differently, which gave us a spare at the end. It also allowed for us to dispose of hard rubble by using as filler between the blocks, and also allowed us to create airflow from the back of the patio to the firepit, which should help aid combustion.
When researching the best materials to use in a fire pit, a few things became obvious.
Don't use river rocks. They will likely contain moisture, which when heated, will cause steam, resulting in the rocks exploding.
Regardless of whichever other material you consider, you will find some articles and advice saying it's a good material to use, and an equal number saying it's not.
One constant in advice advocating against any material is how it will degrade over time with the heat from the fire.
Therefore it seemed to me that the best course of action would be to use a material that is hard-wearing, but also fairly cheap and readily available, so that if the internet pessimists turn out to be right, it can easily be replaced.
For that reason I chose regular house brick as the lining wall. This wall should take the brunt of the heat, meaning I could use a more decorative stone for the outside.
A mix of brick sizes was used for the outer wall, both for aesthetic effect and it also helped fit the available space better.
The wall was topped off with white coping slabs with a mitre. The inner wall sticks out slightly from the coping, giving it a 'lip'. This is by design and will feed into a later project.
The finished patio and firepit. Still a few finishing touches to do, but perfectly usable as it is.
It wouldn't be a post about a firepit unless there was picture of some flames, would it?
I'm fortunate to have a great view over some fields at the bottom of my garden, and I plan to create a patio/barbecue/fire pit area so that I can make the most of it.
At risk of this becoming just another home improvement blog, I have set myself an additional challenge to differentiate it from all the other "I built a firepit in my backyard" projects all over the internet.
The challenge I have set myself with this project is to aim for 'zero-ish waste'. That is, there's inevitably going to be some waste, but to minimise it to the extent that there's no skip or trip to the dump required - to keep the waste minimal enough that it will go in the regular household bin collections. That means lots of re-purposing and re-using of what's already there - stuff that was left behind by the previous owners.
The fence that is currently at the bottom of the garden is in good condition, so I don't intend to remove or replace that, however at sitting-level, it's just high enough that it blocks the view. So the plan is to create a raised patio, so that eye-level when sat down is not obstructed.
Being a large household project, it was more important than ever for me to be able to communicate the project idea and plan to my partner, so I spent some time planning it out in OpenSCAD, to produce this 1 min animation.
The area that the patio will occupy originally contains a greenhouse, and some slabs that have been laid around it.
This will create a solid base without the need to dig foundations.
Fortunately, the slabs are all an even 60x60cm (or 2x2ft), which makes a convenient grid from which to base the design and measurements.
The plan is to leave the right-most column empty, where a planter will be put. The slab in the left-most, plus two slabs from the other side of the garden where the shed is, will be used to square-off the corner, effectively making a 6x4 square patio (12x8ft)
With this solid base created, concrete blocks will be placed to raise the new patio. Gaps will be left between the blocks to minimise the number that we need, with the space filled with any rubble left over from the build.
Slabs taken again from the other side of the garden (they are currently a base for the shed), will be moved over and concreted on top of the concrete blocks to create the raised patio.
Finally, the firepit rings are a purchased kit (sold as quarter circles). We will adapt them slightly so so that the circular wall sits at both ground level and on the patio.
Unfortunately there was an unforeseen obstacle in the the fire-pit kit we were going to use was on a lengthy back-order, and we'd be unlikely to get one this year.
But still, the plan makes a good jumping-off point for a new plan.
Now that I've recently added a welder to my workshop, I need something a bit more protective than just the usual old clothes I use as workshop attire, so I've been planning to build a leather apron.
What makes this project a bit different though, is I have inherited a large box of leather from another leather crafter who sadly passed away. It's a significant amount of material, so I don't really want to go purchasing yet more for this project.
So the challenge that I set myself is to 'frankenstein' the apron together from the smaller pieces, but do so in a way that hides that fact - or at the very least, styles it out so it doesn't look like a patchwork bodge.
I'm using a borrowed canvas apron as a rough template, but will adapt where necessary to suit me.
The largest suitable piece I have is this, which covers most of the area, but the template comes in a bit short at the edges.
A second piece, although a different colour can attach to the bottom, extending it to a more suitable length. This covers the size of the canvas example apron.
I also created edge pieces for the vertical sides of the apron, to tidy it up. When I've used aprons in the past, I've always found an annoyance of them is how the side bits often 'flap about'. To try and combat this in this design, I've enclosed a length of steel wire in there, which should strike a balance of being flexible enough yet maintaining some sense of shape.
There's still the scuffed portion at the top to deal with. This will be
where I affix the straps, so have cut a couple smaller pieces of thicker
leather here so which cover the problematic patch, and provide the
mounting point for the strap. I did the same on both sides to maintain
the symmetry.
There was also enough left over to add a central pocket, which I planned to divide into two.
I wanted all the pieces to be a consistent colour, but not too dark, so I opted for a shade of brown just slightly darker than the pieces were currently.
After dyeing, I fixed the bottom and side sections in place with contact adhesive. This would serve as a placeholder while I stitched them, and add to the overall strength.
Straps
In the box of leather that I inherited, there were what appear to be, a number of several unfinished belts. These were all consistent in the type of leather, so were perfect to repurpose as straps for the apron. All I needed do is dye them to match the colour.
For the shoulder straps I used a single rivet, as this would also act like a pivot and allow flexibility. This was covered over by the top pieces I mentioned earlier.
I joined these in the middle of the back using a small piece cut from thick leather, from which another piece moves downward to join the belt portion, like a 'Y' shape.
Another 'junction' piece joins that to the belt in an 'upside-down T' shape.
The belt itself is simply riveted to the sides of the apron. I made the right-hand side particularly for the buckle, as I reasoned it would be easier to fasten/unfasten from the side of the body than trying to reach behind my back.
Finishing touches
I soon realised that the front pocket would just end up filling with dust, so I made a cover flap for that.
Also used some remaining scraps to add some padding to the straps near the shoulder.
I got a dartboard for Christmas, which I have on the wall in my home office.
Darts is a great excuse for getting up and stretching your legs between video meetings, or while thinking over a problem, rather than just pacing back and forth.
However up until now it's simply had an old piece of hardboard as a backing, so thought it's time it got a proper cabinet.
The design is to have two compartments, the main dartboard cupboard (obviously!), and below that a small compartment which can be used as storage for the darts and accessories, and will open to provide a platform to help catch bounce-outs.
The Frame
The frame is made from a reclaimed iroko desktop - I believe it was from an old school chemistry lab. It's about 5cm thick, so ideal for covering the thickness of the dartboard.
This was ripped down into 4 lengths to make the sides of the frame.
These are jointed using lapped mitre joints, screwed through from the back for extra support.
The divider between the main dartboard compartment and the lower storage compartment is joined into the sides with pocket screws.
The backing of the main compartment is hardboard, reclaimed from some dismantled hollow-core doors, simply pinned into rebates in the frame. The backing of the lower storage compartment is reclaimed laminate flooring, which helps to add rigidity to the structure, again, screwed into rebates in the back of the frame.
I layered some cork over it, to try and prevent bounce-outs and reduce impact noise, although in hindsight I regret that decision, as the thin cork veneer seems to disintegrate at the slightest provocation. But seeing as it's there to catch errant darts, it's pretty much a consumable anyway.
The doors The doors are iroko, edged with oak to add some contrast.
The fold down door for the storage compartment is reclaimed from a previous project which didn't pan out, and is already built in the same manner.
It also has a leather lining, again from a previous project - I don't know how well that's going to withstand some dart bounce-outs, but I don't think it's chances of surviving being ripped out are much better, so opted to leave it in.
For the storage compartment, a leather lace is used to create a limiter to stop the door folding down too far. This simply threads through a hole drilled in the divider and is knotted.
A simple latch for this is mounted in the side, made from miscellaneous brass hardware from the junk bin.
On the door side, the lace is threaded through more brass hardware (I believe a Chubb keyhole cover), and knotted. The knot is recessed into the door to hide it, and the hardware screwed to the door.
The handles
The handles for the doors are made of leather. This is done by creating a loop as shown below.
A hole is drilled through the thickest part (the 3-layer section). Between the second and third layer only, a small screw is placed with a washer.
The first and second layers are stitched together, and the handle screwed to the door. The hole in the first layer provides access for the screwdriver, as the head of the screw is hidden.
When that's done, the hole in the first layer is hidden by the rivet.
Finishing touches
In the back of the cabinet, keyhole hooks were recessed into the top and bottom of the frame. The sides would've been preferable, but the placement on the wall would have collided with cabling behind the wall.
A whole was cut in the centre of the dartboard compartment, this is to allow the existing wall mount to pass through - so the dartboard does still have a direct mount to the wall, which aids with it's positioning on the wall - we can make use of the calculations we did when it was first hung.
Finally, a couple of coats of danish oil were applied to bring out the pattern of the grain.
Clap switches are an old automation gimmick from the 1980s. Basically the circuit hears a noise above a given volume (amplitude), and activates.
This project is an attempt to refine that idea, to create a switch that does the same, but responds only to a given sound (frequency).
This was inspired by watching my partner fail miserably playing South Park - The Stick of Truth.
In the game during battles, there is a timed button press during an attack that increases damage. Timing these button presses was not going well...
That noise triggers at the time the button press is required, so I started thinking about how that noise could be listened for, and the button press triggered.
Band-pass filters
This system relies on the use of a band-pass filter. There are plenty of explanations around about these and how they work, so I won't reinvent the wheel here.
For the purposes of this project, the key point is if the input has a frequency between the low and high thresholds, it is allowed through. Frequencies outside of those thresholds (bands) are rejected.
These can be built in hardware as circuits, but also in software on regular computers.
Fast-fourier Transform (FFT)
This is a well-known algorithm that, in simplistic terms, takes input over time (such as audio), and breaks it down into the frequencies it's composed of.
I'll admit, my understanding of FFTs is similar to the relationship most people have with their household appliances - know how to use it, but can't really explain how it works under the hood. There's plenty of detailed explanation for the more mathematically inclined.
So the basic concept is this
Pipe the audio input into the FFT
The FFT converts it into the frequency domain
Zero out all the values for the frequencies that fall outside of the range we're 'listening' for.
Do an inverse FFT transform, which turns the frequency domain data back into time-domain (i.e. back to real audio). This gives us sound where everything except for the range we're listening for is muted.
This can then be passed into a regular 'clap-switch', where we trigger if the volume of the sound is above a given level.
Finding the target frequency
This part of the process can be trickier than it initially seems. Sounds are composed of many frequencies, so it is necessary to select a frequency range that is unique to the target part of the audio.
To start with, I extracted the audio from the above video clip using FFMPEG, and opened it up in Audacity. This initially shows the audio waveform.
Select the area containing the sound, and select Tools, Plot Spectrum.
This will show the frequencies that exist within the selection. However, this doesn't give us all the answers. Save the plot (I just took the below screen-shot and used that). Then select another parts of the audio and repeat the exercise. Then basically it's a case of spot-the-difference, looking for a frequency spike that appears in our target audio but not the other samples.
A sample spectrum from elsewhere in the audio.
The segment containing the target sound. Circled are frequency spikes not seen in the rest of the audio,
Hardware
To run this switch I'm going to use the Next Thing Co CHIP. This is the same system I used for the TV desk project years ago. Unfortunately these are now discontinued, but there are still many ARM-based SoCs running Linux out there.
Potentially this could be distilled down further on to a smaller microcontroller, although I'd have reservations about how far you could reduce the resources until the processing time introduces enough lag to make it too slow to use.
As well as effectively being a 'proper' computer, the CHIP has general purpose IO pins, like most microcontrollers. This can provide the interface for the output of the 'clap' switch. In this case, for the sake of example I'm just hooking up a simple LED that will blink on detection of the given sound.
Although the CHIP does have microphone pins and the ability to switch it's video pin from the jack to be an audio in, for the sake of prototyping, I found it much easer to just use a cheap USB adapter which has microphone and headphone sockets.
Power comes from a standard USB phone charger.
Control is done via a serial connection to my PC, using Minicom.
Software
As the CHIP is a full-blown Linux distribution, there's lots more flexibility in the software that we use. I ended up using Java and the Apache Commons Math library.
The basic OS was pre-installed, Java 8 JDK was installed from here.
The Java code listens to the microphone input, and allows the user to load a JSON file containing details of the filter to apply - this made testing and refining the filter easier. The values are the start and end of the frequency range to listen for, and the threshold of amplitude to trigger the output (This figure can be a bit of trial and error based on how loud the input is, and can vary if the input volume varies.)
It can also be controlled via command line to either pass-through the audio to the headphones as-is, or post-filter - i.e. you hear what the 'clap' circuit would hear.
Some configuration was required to enable the GPIO pins to be activated on boot. To do this, the necessary commands (below) are wrapped in the bash script
(Refer to the CHIP docs for what exactly these mean)
This is set to run on boot by adding the below line to /etc/rc.local
sh /etc/init.d/preparegpio.sh
Finally, for the Java code to trigger blinking the LED, it triggers another SH script. I went this route as I intend to develop the Java code into a more general purpose audio tool, so didn't want to tie the code too closely to the hardware I'm using for this project.
It also has the benefit that the audio processing doesn't wait for the GPIO operation to complete, thus reducing the lag.
While it certainly does respond to the input audio as expected, there is definitely some processing lag, as can be seen as the video progresses.
This isn't entirely unexpected, and could be overcome by throwing more computing power at the processing (The CHIP is a 1GHz processor), or possibly further optimisation of the code (or porting it to C or similar).
That might be the subject of a follow up project at a later date, but for now, this demonstrates the idea.
December 2022 update: I've developed this idea further, giving the project more features, including the ability to blink lights in morse code. The original post remains below.
With the Covid-19 pandemic still dragging on, it looks like things won't be back to normal in time for Christmas.
At work there was discussion about Christmas parties, team building exercises, and other such things to try to boost morale.
I'm currently working on a project that uses WS2812 RGB LEDs (which'll no doubt wind up published here eventually), and on a whim, wondered if there existed fairy lights that use the same chip.
Turns out, there are. So obviously I had to buy some.
My Christmas tree is positioned so that is can be seen in the background when I'm on Zoom calls with work, so I thought it'd be fun if I could setup some system that would let my colleagues interact with the lights.
Once the lights arrived and I'd tested them, I got to tearing them down.
Wiring
The power supply/controller is a USB unit. I was powering it from a phone charger adapter. That also contained an infra-red receiver for the included remote. I thought about potentially working that angle, but the remote had limited options, and I wanted to offer more granular control.
From the controller to the lights was just 3 leads, which I rationalised must be +5V, Ground, and Data.
I cut the wire, figured out which was which, and connected in an Arduino. It wasn't able to provide enough current to drive the LEDs itself, to I made use of the existing charger - the charger continued to be connected to +5V and Ground, sharing the ground with the arduino's ground, and then the data line connected to the arduino.
The circuit. It works fine like this for short periods, although I later found adding a 470 Ohm resistor between arduino D12 and the first LED increased reliability over time.
Arduino code
I ended up using the PololuLedStrip library, and modifying the existing code for that.
Initially I'd hoped to be able to provide full RGB control, but it just seemed that the sheer amount of data being sent meant bytes were being lost, or I had to slow the data rate down to unusually slow.
Eventually I settled on using 10 preset colours, defined with numbers 0-9, being sent as a 100-character serial string - 1 character (colour) per LED. This seemed to be the best trade off of functionality and reliability.
This is a simple web server that accepts
GET requests for one endpoint, and is simply there to provide a
go-between for the messaging apps and the serial port.
As each LED is individually addressable, I wanted to create a format that would give users control at that level. I settled on messages with the following JSON structure
[1,"colour"]
or
[[1,2,3], "colour"]
where the numbers are the IDs of the LEDs, and the string is one of the available colours.
This would let them control either an individual LED or a series of them in an individual command.
Hooking into Slack and WhatsApp
As at work we use Slack, and we have some previous integration with it, it seemed like the obvious choice.
However, their API functionality is heavily focused on HTTP endpoints, and requires a server to interface with it. That's fine for 'proper' development, but when I'm just messing around at home, I don't really want to be dealing with opening up my home network and all that entails.
Really what I wanted was some client-side plugin functionality. There isn't an official API or interface for one, so I had to improvise.
Using the web-browser interface, and making use of Firefox's Javascript console, I added a MutationObserver to the page, and made use of the DOM to narrow in on the message elements, and get the contents of the latest message in whatever chat/channel the user was in.
Once retrieved, some basic checks are done to make sure that the message is in a usable format and hasn't been acted upon already, it's then passed to a local server via HTTP, where it's processed, converted to the serial format used by the arduino, and sent onward to it.
After realising how useful MutationObserver is for things like this, it was quite trivial to do the same for WhatsApp.
In my previous post, I built a hanging light fitting of live-edge oak and recessed GU10 spotlights.
There is actually more to the project.
Sometimes, spotlights can be a bit overpowering, and it's preferable to have some ambient, indirect light.
During construction, I had the idea of creating this light in a way that would allow use of the spotlights, an ambient light, or both.
To create the ambient light, I used LED strips on the reverse (upward-facing) side, to reflect light off the ceiling.
I cut some thin strips of oak with a 45-degree angle and mounted them in a rectangle on the back - angled side outward, to help direct the light. An RGB LED strip was mounted all around this.
Control
I initially thought of using the LED driver that tends to come standard with rolls of LED strip, but as the existing wiring leads to only one switch, without some rewiring through the ceilings/walls, it would be limited to either having both the spotlights and the ambient light on, or just the spotlights on without the ambient light - it would not be possible to have the ambient light on without the spotlights.
In order to combat this, and to lay groundwork for a potential future
project, I included a solid-state relay and an Arduino. The arduino would drive TIP31 transistors to drive the 3 channels for the LEDs red, green and blue, and additionally control a solid state relay which would act as the switch for the spotlights.
The idea would then be that the light switch would remain
on, more like a utility switch, and then all control of the light
fitting would be handed over to the Arduino.
Power
The original wiring sketch. it's just a rough sketch, not a proper wiring diagram.
The LED strips take 12V, and the microcontroller takes 5V, so a PSU is needed to bring the power down to usable levels.
For this I used an old net-book power supply. This was wired into the back of the light fitting. Caution is needed to make sure that nothing too powerful is used, as typically a houses' lighting circuit breaker is tripped at a much lower current than the mains sockets.
Revised to include the additional components
This would normally be plugged into a wall socket, where
it's plug would have a fuse. However in order to wire this into the
lighting wiring, the plug would need to be removed - obviously this
introduces a safety concern. To ensure that this would still be fused, I
replaced the wall switch for the light to one that includes a fuse,
ensuring that the light is behind the fuse.
Communication
To communicate with the Arduino, I used a cheap HC-05 bluetooth to serial adapter, the same as I've used in other projects like the Bluetooth Macro keyboard app.
The arduino receives 4 bytes, followed by newline characters. These correspond to 1 byte each for the red, green and blue channels in the LED strip, and the final byte is either a simple 0 or 1 to indicate if the spotlights should be on.
For now this is sent by pairing with my phone and using a bluetooth serial terminal app from the Google play store. I'll probably create a more custom app in future, but for proving the concept, this works just fine.
