Since lockdown in 2020, I’ve continued to work remotely, and sunk a fair bit of time and effort into optimising my home office setup.
One thing that has continued to be a pain is having my laptop on the desk.
I don’t use it has a laptop the majority of the time – is it is closed and I use external peripherals (monitor, keyboard, mouse, microphone and camera). But it continued to take desk space as I had nowhere else to put it.
I had this idea of creating a mount on the side of the desk for it, but couldn’t settle on a approach or material to use. Wood would be too bulky, metal would be overkill and block wifi signal, and so forth.
Plastic seemed like the best option, but it would be far too big to 3D print.
When researching methods for manipulating plastic sheets, I found this video by Youtuber Dietec for a home-built acrylic bending tool.
Truth be told, I followed the video pretty much to the letter, so there’s no point rehashing all the points that are made.
The only main difference is I added a couple of toggle clamps on the side, and am using a “Universal” laptop power supply instead of a bench top one.
Anyway, back to the laptop mount.
It’s very simple really, take a sheet of acrylic and bend it into a ‘J’ shape, attach it to the side of the desk, and add laptop.
The piece of acrylic was recovered from an old scrapped project, and was a bit on the short side, however this could be overcome by mounting it lower on the desk skirt.
The bending process seemed quite straightforward. I did notice some crackling in the corners of the bends, I believe this is because I got impatient and stepped through the voltage settings a bit quick, rather than give the material time to heat slowly – so that’s something to bear in mind for next time. I think that's also why there's a slight curve to the lip, as can be seen in the picture below.
Then a couple of screw holes were added (taking advantage of pre-existing holes from the previous project and just widening them), and then screwing it to the desk skirt.
The laptop in place on the mount, tucking nicely under the lip of the desk at the side. Sure it's not a perfect build, but it serves its purpose.
Since building the treadmill project late last year, I did actually
manage to complete a full run through of the original Sonic the
Hedgehog.
Along the way I found a few snags and
issues with the treadmill:
Direction switch/lever
I soon found that the reed switch
control from the cross trainer levers was problematic because there
was a lack of tactile feedback to know when the lever was in the
correct position for changing direction.
Therefore, I replaced it with a
regular switch where normally open connected the ‘right’ key and
the normally closed connected to the left key. Using a metal angle
bracket I was able to mount it to the frame so that the switch is
closed when the lever is fully forward, and open in any other
position.
This means that when moving right I
just need to keep the lever fully forward, and to change direction I
just have to move it from that position.
Although I kept them in place for the
duration of the Sonic play-through, I’ve since removed the cross
trainer levers, as they do not provide any real benefit over a
regular button.
Jump button
The large plastic button that I was using as a jump key broke (it
was from a cheap “noise-maker” type toy, and the PCB literally
snapped), so that was also replaced with a basic switch. I plan to
change this up for something better in the future, but at the time I
just wanted to go for a run.
Quick save and quick load
I found, particularly on the
more platform/puzzle sections of the game, it became necessary to
make use of the quick save and quick load features of the emulator,
so I added an external quick load button to the treadmills handlebar.
A better button system
All of the above can be distilled to a single point - that the button inputs were not good enough.
Although I started the project with the intention of minimising the number of regular button presses, it seems inevitable that there will always be some required.
Configuring the controls
In order to play other games I would need to make some additional
adjustments for different control schemes. This would mean altering
the firmware and re-uploading every single time I changed the game,
which seemed needlessly convoluted.
There were two main reasons for using the Makey Makey. The first
was to take advantage of its noise filtering features, and the second
was its ability to act as a keyboard.
The noise filtering is the real selling point of using it, but
there are other ways to obtain its input and then turn into keyboard
input. So I adapted the firmware so that instead of sending keyboard
input it would appear to the connected computer as a serial port. On
each cycle it would send one byte, with each bit representing the
button state (i.e. pressed or released) of each of the buttons.
This would allow a data transfer rate fast enough to handle pretty
much any input I can throw at it.
The software will be an ongoing development project so I’m not
going to be sharing it at the moment.
On the computer side, an application
will continuously read the serial import, and then translate it into
appropriate keyboard events via udev, thereby sending whatever that
keyboard input is to ever application is active and in focus on the
computer – in the case of this project that will be a game.
For this iteration of the treadmill
I’m going to be using the acclaimed indie game Super Meat Boy –
as it has a small range of inputs (left, right, sprint and jump) but
adds a couple of extra bits of complexity for me to expand on with
the treadmill.
Once the serial connection is established, a thread runs
constantly, reading the latest byte from the Makey Makey.
It compares the byte to the previously read byte. If a bit that
wasn’t previously set is now set, then a corresponding function is
called in a secondary thread, which is the input thread.
The input thread maintains a count of “presses” from the
treadmill rotations, which increases with each press as well as
decreasing with the passing of the specified time interval (the
“decay”).
If the count is positive then the first key (the direction) is
pressed.
If the count is positive and greater than the defined sprint
threshold then the sprint (shift) key is also pressed.
For the jump key, the serial thread will always report the state
of the relevant bit to the input thread.
This compares a pair of booleans (jumping and lastJump) – which
determines whether the jump (space) key should be pressed or
released. It is done this way because Super Meat Boy differentiates
between small and large jumps based upon the duration of the key
press.
When I started woodworking, a key motivator was simply financial - make stuff myself and save cash.
A recent trip to the garden centre, where they were selling these wheeled flower pot stands at absurd prices, convinced me to get back to basics and make my own.
There's nothing complex about this build. Simple pallet wood - all from the same pallet to keep consistent appearance, and avoid the need to process the wood too much (planing, thicknessing etc)
A simple grid of five slats with gaps in between and two perpendicular underneath, all 40cm in length. Each overlap with two screws - the only 'gotcha' being to be mindful of the screw placement on the end ones, given that it'll be cut into a circle.
Then simply cut into a circle with a jigsaw, and a quick sand to remove sharp edges.
Four wheels from an old office chair were attached - these are simply push-fit into a drilled hole.
That's all it took - literal junk (pallet wood, wheels scavenged from a binned chair, and even the screws were from the 'miscellaneous' jar). Whole thing took less than a couple hours and saved about thirty quid.
This is another one of those projects I found on Pinterest & decided to make a DIY implementation of. The original pin describes it as a “picture and collection bar”.
Essentially using a wooden strip to trap marbles in such a way that they have a little movement but due to the sloped design will always try to move downward and towards the wall.
This means that if you push a piece of paper through the gap at the bottom, there is enough movement for the marbles to get out of its way but they will immediately roll down, providing just enough friction to hold the paper – but not enough friction to prevent you from easily removing the paper again if you need to.
It’s kind of like an ultra slim pin board, but without having to put holes in your paper.
Design The original design I found used pretty thin strips that appear to be jointed it mitred angles.
Instead I opted for using a larger piece of oak, but then cutting out an angled gap for the marbles.
The cross section looks something like this:
Construction The actual construction of this was very simple, just a series of rebate cuts on the table saw, occasionally making one of them angled, and making one very us at the bottom of the piece, so that when it’s up against the wall there is a slight gap as can be seen in the above diagram, which will allow paper to pass through.
Then I capped off the ends with a little piece of mahogany, to prevent the marbles from rolling out the sides – this is simply glued and pinned in place – and then finally some finishing.
As the piece of oak I was using was reclaimed and had a couple of screw holes, I patched one which looks a little bit like a knot in the wood, and the other two which were at the edges, I decided to patch using brass tacks, as the holes were in a position where if I were going to screw this to the wall I would have put holes anyway.
Mounting The tricky part of this project is mounting it to the wall. My design does not have a back piece because I did not want it to protrude too far from the wall. The downside of this means until it is on the wall, the marbles could fall out the back.
So, firstly, I filled the back with some marbles.
I then used gaffer tape across the back of the marbles and the lower part of the bar – leaving the side top bit exposed as this is where the adhesive is going to go. I left enough excess gaffer tape to be able to fold it round so that there was a ‘handle’ hanging off the bottom of the bar.
Obviously the next step is to mark out a position on the wall to mount it, make sure that it is level, etc. Then apply the glue to the back of the bar, and stick it to the wall.
Once you’re confident that the glue set, you can put on the gaffer tape ‘handle’, to peel the tape away from the marbles on the back, releasing them.
As I mentioned in my previous post when I was restoring the sewing machine, the electronics were in a pretty bad state.
I believe the pedal was meant to allow for variable speed input, but in reality it acted just like a simple on/off switch, and pressing the pedal down the whole way tripped the circuit breaker.
Inside the motor housing once the rotor had been removed.
Initially I tried just repairing what was there, replacing brushes in the motor, cleaning it all up – which seemed to provide some temporary improvement but it soon deteriorated again.
So I decided to just try and replace all of the electronics with modern equipment, but retained the original casings to try and maintain the rustic aesthetic. I figured with modern advances in electronics it is quite likely that a lower power, modern motor would be able to provide comparable performance to the old one (the analogy that springs to mind is the state of modern cordless power tools versus old mains powered ones).
It is clear that the original motor does not have any kind of gearing to boost power – the circuit seemed to be about as basic and simple as it gets.
As I was researching the old motors I did see some mention about potential asbestos hazards – this is near the bushings of the motor – it is intended to support the bushing and act like a self-centering bearing. As I am entirely replacing the motor I had no need for it. With appropriate protective equipment in place I was able to remove it and dispose of it appropriately.
There was also mention about the being asbestos washers in the foot pedal, however my one does not appear to have these – but nonetheless I will not be using this pedal anyway.
One side the case of the me to opened up I was able to pull out the coil windings and rotor, leaving an empty shell. I removed the original connectors.
The screwdriver To replace the motor I am going to use a cheap cordless screwdriver. Being cordless it should be adaptable to run on a lower power, but given the task that it is designed for, it should still be able to provide enough torque to run the machine due to it’s gearing set up.
In these cordless screwdrivers all the electronics tends to be in the handle, so it is easy to separate out the motor and gearing system from the rest of the device.
With that done I needed to trim off some of the casing to get it to a suitable size to fit in the sewing machine motor case.
The only modification I needed to make to the sewing machines motor case was to drill out the opening slightly as the shaft of the screwdriver was a little bit wider, however this is not actually visible from the exterior.
To mount the screwdriver, I 3D printed a mount (Github/Thingiverse).
It's simply a friction-fit wedge that goes around the screwdriver body and into the sewing machines original metal case.
The diameter of the shaft of the motor is the same as the original motors pulley, but worth bearing in mind that the new motor is slower. I had the idea to increase the diameter of the shaft, in order to change the gearing between the motor and the sewing machine and get a bit of a speed increase. It should also increase the grip on the pulley as there will be a larger surface area of the belt in contact with the shaft.
To do this I created this (Github/Thingiverse). It fits within a small section of aluminium tube (to prevent wear on the plastic), and over the shaft of the screwdriver. It's locked in place with an allen key (cut flush) that fits as if it were a screwdriver bit and locks into this plastic widget. Finally I locked it all together with some adhesive and wrapped a bit of grip-tape around the aluminium.
Driving and control To drive a motor I am using a BTS7960 motor driver, controlled by an Arduino (for now, for the purposes of prototyping).
Simply this will be an analog input, which the arduino will translate into pulse width modulation (PWM) and send to the motor driver. This is possibly overkill, but the priority at the moment is too get the machine working – optimization & improvements can come later.
For now, I have a simple potentiometer to set the PWM, and the pedal is actually just a switch cable tied to the legs of the sewing machine. I am hoping to be able to get a treadle foot pedal like those that would have traditionally been part of the table legs that I’m using, and use that – if I’m ever able to find one.
Pulley Belt The belt connecting the motor to the machine was worn through and hanging on by a thread, so it needed replacing.
There
seems to be a lot of various DIY how-to ways suggested to create pulley
belts to size, so I started working through those. The results were:
Pulley belt from an old printer cut to size and stitched together using fishing wire - failed - snapped.
As above, but joined with glue and stitched - snapped.
Electrical
wire (speaker cable) threaded together, and heat-shrunk to provide a
rubberised grip. This seemed promising - it didn't snap at least, but
the heat shrink, although intended to provide grip, seemed to have the
opposite effect.
After all that, as a temporary measure, I
joined 3 nylon cable ties together, just so I could move on to the rest
of the project. And as the saying goes "There's nothing more permanent
than a temporary fix", it's still going strong.
Light The motor housing also contained a small lamp fitting. This was previously a mains powered, incandescent, bayonet fitting bulb. However I rewired and replaced this with a 12v LED bulb – much in the same way the I did with the Sunset Sarsaparilla lamp project.
Power Power was provided by an old desktop computer power supply. This provides 12v lines for driving the motor and the light, and 5v for the logic. Again, this is another quick prototyping move, and will eventually be replaced by something nicer.
Finally all that was left was to oil the machine as indicated in the original manual, and give it a try.
This year whilst I was doing that, I took the opportunity to add a
few new features and simplify the interface.
Now it responds to some key words – all, top, bottom, half,
alternate, led, and allows the user to specify certain colours by
word and all colours by hex code.
Additionally I refined the serial interface to speed things up.
Moving to a single-board computer
For my home implementation of this, previously I would just run a USB extension lead from my desktop.
I have now migrated the code to a PCDuino2 single board computer. This is a 1Ghz Allwinner A10 chip SBC, which also contains Arduino pin headers.
The board is discontinued (I bought this one from Maplin years ago during their closing down sale), and as a result there is little in the way of official repositories or archives for the Ubuntu variant distribution that it runs. Plus it looks like there’s some sketchiness around the official firmwares around the allwinner chip that powers it.
I found a version of Armbian linux for this platform and burnt it to a micro SD card. This allowed me to get the PCDuino to boot to Armbian.
Unfortunately it looks like there is no real support for installing Armbian to the NAND storage which is on the PCDuino. However, leaving it on the micro SD has some advantages such as easily being able to image and back up the install.
Then it was simply a case of connecting it to the network and updating it, enabling SSHD for ease of maintenance going forward, and installing required tools for the Christmas lights server (JDK and Arduino).
As the PCDuino is not a typical Arduino development board it needs its own board definition to be used with the Arduino IDE, so for now I decided to continue using an externally connected Arduino.
Implementing morse code
One of the downsides to the set up the I currently have is that the serial data transmission can be disrupted by the update process transferring data from the Arduino to the lights.
The changes I have made reduce the amount of data that is transmitted via serial and so minimize the problem.
However there is additional functionality that I wish to add that will require further data to be transmitted – that is to have a set of lights which flash similarly to regular Christmas lights, but instead of a standard or random pattern, they blink out morse code, based on a message input from the control application.
Rather than cram more functionality into the WS2812 lights that I am currently using, I plan to leave them be and use a regular set of plain white fairy lights for this. Typically I have always decorated our Christmas trees with a multi colours set and a plain white set, so this fits with what I would typically do anyway.
The lights I used are powered from 3xAA batteries (4.5v), which can easily be substituted for USB and powered from a USB hub. To toggle their on and off state, I have used an optocoupler which will be toggled from the PCDuinos GPIO pins.
The ‘arduino-style’ pins of the PCDuino board can be reached in be linux file system via GPIO – similar to the way I toggled an output pin on the frequency switch project.
Seeing is this makes it quite easy to simply toggle a pin on and off, I should be able to use this for the morse code without having to depend on the rather outdated and no longer supported PCDuino board definitions.
Finding the pin reference
A ‘gotcha’ about using the sysfs GPIO interface is that the pin numbers as they may have silk screened on the board do not necessarily correlate to the pin numbers in the file system.
The first thing to do is figure out what the pin identifier would be. In this instance, I found some config files for the PCDuino on GitHub.
There lists the PCDuinos GPIO pins and there corresponding identifier, summarised below.
GPIO Pin
Pin ID
0
PI19
1
PI18
2
PH07
3
PH06
4
PH08
5
PB02
6
PI03
7
PH09
8
PH10
9
PH05
10
PI10
11
PI12
12
PI13
13
PI11
14
PH11
15
PH12
16
PH13
17
PH14
18
PH15
19
PH16
I’d decided to use GPIO 8, so the relevant ID is H10
The
Sunxi wiki
demonstrates how to calculate the relevant GPIO number from that ID
(position of letter in alphabet - 1) * 32 + pin number
so with H10, H is the 8th letter so
(8-1)*32 + 10 = 234
So
with that number calculated, we can export the pin with
echo 234 > /sys/class/gpio/export
which will make ‘gpio234’ available under /sys/class/gpio.
From there we can make it an output, and change the ownership so
of it’s value file so that a regular user can write to it.
echo out > /sys/class/gpio/gpio234/direction
chown -R ant:ant /sys/class/gpio/gpio234/value
Then to switch the lights on,
echo 1 > /sys/class/gpio/gpio234/value
and
echo 0 > /sys/class/gpio/gpio234/value
to turn them off
A demo video is below, and as usual the source is available on
GitHub.
Like a
lot of people, I spend a lot of time trying to balance the need for
exercise and fitness with the desire to sit on the couch and play
video games.
So I figured why not combine the two.
To start with I picked up a treadmill – this one is a manual
treadmill as I want its movement to be dictated by my running, not by
some electric motor.
There
is a small control panel on the treadmill which provides some
statistics.
It is completely optional
and not required to use the treadmill. It
gets it’s power from a
separate battery supply.
Although this is not particularly
useful to me, it does indicate there is some type of encoder in the
treadmill assembly to measure these values. Before even taking the
treadmill part I can surmise that this is most likely either a magnet
and reed switch assembly, a hall effect sensor, or a rotary encoder.
Once I got the treadmill, I could see
a simple 2-wire lead from the base of the unit through to the control
panel, connected with a 3.5mm jack.
I breadboarded a small breakout so
that I could connect the oscilloscope and see what kind of signal was
being passed.
This revealed that there’s 2.5v being sent down the line (tip of
jack is positive), and that the signal would transition between high
and low as the treadmill was used, and the frequency would increase
as the speed increases.
In it’s most basic form, if we can
translate those state transitions to key presses, that should work.
There was however a whole lot of noise
in the signal which seemed to be caused by resonance in the treadmill
frame, as there would be severe jumps simply by my touching it.
Initial
Implementation
An initial attempt to use an Arduino
and have the signal trigger interrupts wasn’t successful due to the
noise, and filtering attempts became quickly time consuming.
The requirement for the
filtering and the requirement for it to be an input device led me to
a MakeyMakey development board.
This
board is advertised as an educational toy, that allows users to turn
anything into a key. In order to do this it provides a significant
amount of signal processing and filtering. So in other words, exactly
what I’m looking for.
This means that very
little is required on the software side, as the Makey Makey presents
inputs to the computer the same as a keyboard would, and
applications generally will not notice any difference.
By simply connecting a crocodile clip
from the tip of the 3.5mm jack to an ‘key’ on the Makey Makey,
and connecting the body of the jack to the ground of it, that is
already enough to get some response. Every pulse sent by the
treadmill gets interpreted as a key press and release by the Makey
Makey.
Problems
The only problem with that is with the
treadmill in normal operation, the pulses (and therefore keypresses)
are so quick that they do not translate real world movement into
equivalent in-game movement.
With the treadmill running, the red marks show the time that the key is pressed. The two ‘bursts’ of movement on the treadmill appear as a total of 14 short keypresses.
Instead, either the rapid tap causes the character to barely move, or
if the treadmill stops when the signal is high, the character runs at
full speed without needing any further movement on the treadmill.
The treadmill stopped when the signal is high – making it look like the key is held down indefinitely, even though the user is not running
What I want to do is to bring the game input more “in step” (ha)
with the movement of the treadmill, so that the same two bursts of
treadmill movement would look more like the following:
The two bursts of activity are represented as two longer keypresses, as if the key were held down for the time the treadmill is moving
To do this, I forked the source repository of the Makey Makey project, and made some edits.
The
changes are mostly in the
updateInputStates function, and focus
on the ‘right’ key on the Makey Makey, as I will be using a
side-scroller game to test.
Demo
To demonstrate what this change does, below are two screenshots which represent a few seconds of continuous running on the treadmill. The first is with the treadmill connected to the “Up” key, which is unaffected by the code changes. The input is shown as repeated press and release events. The second is with the treadmill connected to the “Right” key, which is the one that I have changed. The impact is shown any as press events, up until the point that the treadmill stops. This is the same as if the key were held down.
The test code is based on KeyEventDemo
– the only change is that I removed the KeyTyped event as it is not
relevant to this exercise.
Implementation
Unfortunately there is no way of determining the treadmills direction
of travel as it was obviously not designed for that, but in a game I
may want to change direction.
What I have done is a workaround for
now is I have made the same change for the left key as I did for the
right and have wired the treadmill to the Makey Makey like so:
This means by simply flicking the switch I can change direction. In a subsequent moment of inspiration I swapped the switch for a pair of reed switches and a magnet attached to one of the cross-fit handlebars that are on the treadmill - allowing for the direction to be controlled with the left lever.
I
have also wired a simple momentary switch to the space key to allow
my character to jump.
For now this whole contraption is held
together by screw terminals and crocodile clips as it is only a
prototype and is a platform I want to expand on in future.
The Game
For this initial experiment I wanted to use a game where input is
limited, as a proof of concept.
To keep with the theme of running and
speed Sonic the Hedgehog seemed like a suitable choice.
I will be running this on a PC with a
Sega Genesis/Mega Drive emulator.
Please note the various copyright and
legal complexities around the use of emulators and ROMs - the short version is that you should not use ROMs of games you don't own.
I actually own two copies of the game - an original Mega Drive cartridge, and a PC version as part of the "Sega Mega Collection Plus". It's just that the Mega Drive emulated ROM is easier to interface with.
