Mooplog

New Site With Pelican Static Site Generator

2017-02-06T20:57:00+00:00

You may noticee that this site now looks completely different.

I decided that I was bored of paying for an AWS instance to host WordPress, and restarting PHP when it crashed, and so on. I also got tired of the massive stall when my tiny AWS instance struggled to create a new post.

I've been thinking about writing my own static site generator for a while, but I didn't want to commit the time to it when there are more interesting projects and it's something that's been done before.

After a bit of research I decided I'd try out Pelican. I'm a fan of Python anyway so I'm right at home editing the config files and I know what I'm doing if I need to make any tweaks. I've played with reStructuredText when writing documentation at work so I know the appropriate syntax for writing content too.

Even better it supports importing from WordPress. I did have to make a few tweaks to remove some markup that didn't convert correctly. Fortunately that was a one off job and it became trivial with the aid of some simple vim macros.

There are probably a few more issues I need to sort out but I'm happy enough with the current state of the site that I've switched it over to the Pelican version.

There's no commenting supported yet. I might bring over the archived comments at some point by appending them to the appropriate posts. If I decide to enable comments again I'll probably try out Disqus unless I find a better alternative.

I'm currently hosting this on GitHub pages. We'll see how that pans out, but I like git and it's free, so seems like a winner so far!

I realise that I've namechecked a bunch of marmite software that will make some developers howl with joy and others with rage. Maybe it's for the best that there is no comment system yet!

RetroChallenge 2016/10 - One bodge to fix them all

2016-11-02T21:35:00+00:00

It's two days past the deadline, but I found an extra moment to work on my SD card interface today and I have it working!

I switched the clock output to the SD card from SH_CLK to /SH_CLK to move the rising edge of the clock to a point where the output from the shift register is stable, and now it works nicely.

This eliminated the critical timing that the Bus Pirate was have gotten away with but my circuit did not.

Once I had this working I checked that the 74HCT595 was clocking the data coming back from the SD correctly. Since my test program soft resets the rc2014 when it finishes I was able to check this from BASIC.

Now that this is working I need to write a (less messy) program to fully initialise the SD card and switch to fast mode. Once that is done I will verify the schematic by rebuilding the circuit on stripboard from the schematic, before designing a proper PCB for the circuit including a proper SD card socket.

There are also a couple of potential minor hardware improvements to investigate:

As noted in my last post that it's likely that I can get rid of the second 74HCT374 and switch to just using the simple edge trigger circuit.
Fast mode should be pretty optimal when used with the Z80 OTIR instruction to write many bytes of data from memory straight to an IO port, however for reading data from the card I currently need to alternate writing 0xff and then read the result back with with an IN instruction. I can use the INI instruction to automatically keep track of where the read bytes should go in memory but I can't use the INIR instruction which would be faster. Some extra logic to (optionally) trigger a write after a read would allow me to use INIR to read blocks of data with the implicit write priming the input shift register with the next byte after each read.

Finally, here's the final schematic:

Even though I didn't quite get it done within the deadline I can call this RetroChallenge a success (it was definitely good motivation).

For bonus points I managed to use exactly all the gates in the 7400 quad NAND and 7404 hex inverter that make up my glue logic.

Now it's probably time to start reading the CP/M BIOS Alteration Guide!

Retrochallenge 2016/10 - Tools

2016-11-01T20:00:00+00:00

During Retro Challenge I needed a way to run machine code on my rc2014, as BASIC was incapable of the performance needed to initialise the SD card in bitbang mode.

I didn't (and still don't) have an EEPROM burner when I first got my rc2014, and although the version of BASIC in the stock rc2014 ROM does support the USR() function it appears to jump to a hardcoded address within the ROM so this didn't help me much.

I ended up finding the assembly language source of the BASIC interpreter (or one very similar) and noticed that the address the USR() function jumps to is not looked up directly from the ROM, but copied to a block of information kept in RAM. Once I knew the address of that block I was able to modify it so USR(0) would jump to an arbitrary address.

With this method I was able to poke in arbitrary code and execute it, but this was far from an ideal workflow.

To improve this I wrote some Python scripts which would output the BASIC code to load a binary image into the RC2014's memory at a given address or run code from a given address. Once appropriate delays were added to avoid overflowing the (1 byte) input buffer on the RC2014's serial port I was able to combine these scripts with z80asm and a makefile to make a nice toolchain for rapidly deploying and testing programs to the RC2014.

By writing the program such that the RC2014 jumps back to the reset vector at address 0x0000 programs can be developed without the need to constantly reset the RC2014 (unless something goes wrong in the program).

I set up my Makefile with additional commands to output hex dumps of the program, annotated assembly, or to run a program that is already resident in memory.

The only issue I've encountered with this system so far is that it is quite slow to load large programs. For my Retro Challenge project the load time was so long that I had to wait for it to finish before reissuing the run command. The automatically sent run program was lost because the loader was still running.

This could be improved by writing a faster loader in assembly which could be bootstrapped with a very small BASIC program. If I had an EEPROM burner a replacement boot ROM could be made which would boot straight into the fast version of the monitor program.

The scripts and Makefile I used are on my GitHub under the RC2014 Tools project. They will work on a Linux system or similar, or on Windows with some modifications.

Retrochallenge 2016/10 - Deadline

2016-10-31T23:08:00+00:00

I'm at my deadline for RetroChallenge 2016/10 and unfortunately I'm tantalisingly close to having something that works, but not quite there.

I have the bitbang/slow mode working and generating pulses that match the output I get from my Bus Pirate when using it to talk to the SD card. However, the Bus Pirate gets a response and my circuit does not.

I blamed my level shifter for a while. As an experiment I tried writing to the card from the Bus Pirate and reading the response through the level shifter works fine, so that can't be the problem.

Bitbang mode was fixed by adding an additional edge trigger circuit. Instead of a synchronous edge trigger I used the simple trick of feeding a signal and an inverted copy of the signal into an AND gate. When the signal goes high the inverted version remains high for the propogation delay of the NOT gate used to invert it, so the output from the AND gate is temporarily high. Since I had a free NAND gate and second free NOT I used these to build an AND. I ended up picking the existing EDGE signal (ie. the synchronous edge trigger) as the input to the new edge trigger. This provided a signal that could be used to make the output flip flop's latch transparent for only a brief period.

I could probably at this point do away with the synchronous edge trigger and save a mostly unused 74HCT374, but there was no time to test this today. I will test this when I get chance.

With the bitbang mode working I was able to attempt to initialise the SD card at the low clock rate it requires. After some fiddling I discovered that my output pulse train was off by one relative to the clock pulse. In an effort to get things to work I bodged the values I was writing to make the output signal match what I see when using the Bus Pirate. This included adding a new bit to the CONFIG register to drive the serial input on the output shift register. This ensured the Data Out line (MOSI) to the SD card was pulled high, in order to match exactly the Bus Pirate's behaviour.

It was difficult to get a screenshot that captured the whole pulse train, but the above shot shows the Bus Pirate sending CMD0 (0x40, 0x00, 0x00, 0x00, 0x00, 0x95) and receiving 0xFF (no response) followed by 0x01 (OK). The shot below shows the commands sent to the Bus Pirate and the response.

The next shot shows my circuit sending the same output, but recieving no response.

In both cases a large number of clock pulses were sent with the SD card's chip select deasserted, as is apparently required to initialise the card.

My suspicion is that either my timing is too fast - I'm currently running at 330kHz while the Bus Pirate is running at 33kHz - or the rising edge of my clock is very subtly off with respect to the data.

There are still hardware bugs (the off by one issue, mainly), but the final schematic and final netlist are included below for posterity.

I plan to continue working on this project after RetroChallenge and will and post further updates as I figure it out.

I also plan to write a post about the toolchain I have setup for running assembly programs quickly and painlessly on the RC2014. Hopefully I'll be able to post that tomorrow.

Retrochallenge 2016/10 - State of Play

2016-10-31T17:11:00+00:00

As it stands my RetroChallenge entry is close to working, but not quite there.

The fast mode appears to work and I was able to decode the SPI packets sent to the SD card with OpenLogicSniffer's SPI analyser module.

The picture above shows the signals and the decoded data for the SD card CMD0 (Software Reset) message which is the first step in initialising the card. The message is the 6 byte string 0x40 0x00 0x00 0x00 0x00 0x95 where 0x40 is the command (bit 6 is always set), the four 0x00s are the empty parameter section, and 0x95 is the checksum for this command. More information on the SD card SPI protocol is available on this page, which I've been referring to regularly for this project.

The eagle eyed will notice that this capture shows an 8mHz clock and therefore the device is running in fast mode. For the SD to initialise correctly it needs to be initially clocked slowly (100-400kHz).

Unfortunately, the slow mode, which I was expecting to be the easy bit is currently not working due to a hack I used to get fast mode working.

The current schematic, seen above, shows that the 'Shift /Load' input of the output data shift register (U3 pin 1) is driven by the SHIFTING net. This gave the correct timings to load the register when data was written, as the register's input latch would be transparent while SHIFTING was low. SHIFTING goes high while the autoshift register (U7) is outputting a 1, so the last value seen by U3 is latched in just before the train of clock pulses is generated.

This breaks slow mode because SHIFTING is always low when /BITBANG is asserted, so the output from U3 is always a copy of whatever is on bit 7 of the data bus.

This should be fixable if I can find a better way to load this register before time runs out.

Retrochallenge 2016/10 - Breadboard Fun

2016-10-30T23:13:00+00:00

Having finally found time to start breadboarding my SD card interface I first made sure that the edge trigger circuit I had tested in ModelSim would work when built with real components.

An issue I had encountered previously when breadboarding RC2014 peripherals was that if I wanted to disconnect the circuit from the RC2014 I would lose track of which wire was which. To work around this this time I took an unused RC2014 protoboard module and soldered on just the usual 90 pin header and a socket header below it. The protoboard can still be used later (minus one row of holes) and now provides something that wires can be plugged into that can be removed from the RC2014.

With the edge trigger circuit built I tested it using my Open Logic Sniffer, which has been an invaluable tool for many projects. I did however notice that running on the RC2014's 8mhz clock brings the Open Logic Sniffer quite close to its limits. The 200mhz maximum sample rate provides resolution for only about 12 steps within each clock cycle, so there is limited scope for playing with gate delays.

Once the edge detect circuit was proven to work I started building the rest of the circuit and things quickly got complicated.

The image above shows the almost complete circuit, but with a loopback between the input and output shift registers where the SD card would normally fit, and some blinkenlights on the outputs from the input shift register to indicate its state before it was connected to the data bus.

I spent quite a long time debugging why the signal coming into the input shift register was always off by one bit. Initially I blamed timing issues in the glue logic and spent quite a while experimenting with inserting delays to try and fix things. Eventually I realised that I was clocking both the Shift Clock Pulse input of the 74HCT595 and the Store Clock Pulse (which latches values from the shift register to the output shift register) with the same clock signal. This resulted in the output register always showing the last but one state of the shift register. Switching the Store Clock Pulse input to an inverted copy of the clock signal fixed this and I was able to send any byte from the output shift register to the input shift register with the circuit operating in autoshift mode.

Previously when breadboarding I had been building the circuit in KiCAD, planning out the breadboard layout as PCB, then building the circuit based on that design. Any changes made on the breadboard had to be updated in KiCAD or things got very confusing.

Unfortunately this mechanism got onerous once I started making changes on the breadboard. Following traces on the screen is no easier than following them in the real world and long jumper wires were hard to route in KiCAD without using many extra layers.

For the most recent attempt I decided to try a more old school approach and build a netlist representing the breadboard contents on paper. I made and printed some templates in Google Sheets, annotated the existing breadboarded design onto the sheet, then kept it up to date as things changed. This turned out to be a lot more convenient than keeping track of the design in KiCAD as it was easy to search for a signal by name and the paper was easier to reach on my desk.

Retrochallenge 2016/10 - Due diligence

2016-10-30T22:45:00+00:00

To avoid the work done designing my SD interface being wasted I decided to verify the concept before going any further.

I used my Bus Pirate to verify that the SD card I have would respond to the commands I expected using the protocol I expected.

The Bus Pirate supports many bus protocols including the SPI bus that the SD card supports in the mode I'm using.

I don't have an SD card breakout board so I ended up buying a micro SD card with a standard SD adapter and soldering some right angle pin headers to the pads. This gave me an SD adapter that would plug into a breadboard.

I initially used the Bus Pirate's probe cable as a quick way to connect to this adapter, but this got frustrating as the mini grabbers had a habit of letting go at inconvenient times. To get around this I made a quick adapter on some stripboard.

This little adapter also makes it easy to remove the SD adapter from the Bus Pirate without having to look up the pinout again. It should come in handy on future SD card related projects and maybe for writing raw data to the SD card.

Unfortunately I don't have any logs of the session, but with this adapter and the Bus Pirate I was able to initialise the SD card and read blocks of data. This gave me confidence that my project would work and would be worthwhile.

Retrochallenge 2016/10 - Building retro computers with modern tools

2016-10-23T20:26:00+01:00

I've been struggling for free time this month for poking around with breadboards and other fun things. To work around this, and still (hopefully) get my RetroChallenge entry done, I decided to use a simulator so I could work on it with my laptop whenever and wherever there was time.

For an earlier RC2014 project I used LogiSim which is simple and easy to use, but I quickly hit some limitations. The built in sequential building blocks (shift registers, latches, etc) appear to support only a limited set of variants. There is no option for asynchronous resets, or transparent latches on the shift registers. It includes combinatorial building blocks (logic gates, etc) also, but these do not appear to work correctly for building sequential circuits, as feedback is not always handled correctly. Because of this I was not able to simulate the exact characteristics for most of the 74 series ICs I was using.

To solve this problem I switched to using Altera Quartus to build a model of the circuit and ModelSim Altera Edition to simulate it. I mainly chose this because I've used it previously for FPGA projects, and because if some functionality is missing I can implement it in Verilog.

When redesigning the autoshifter circuit (to shift out 8 bits of data after each IO write) I built it as a Block Diagram/Schematic File (.bdf) in Quartus. This allows the design to be entered as a schematic with various logic symbols supported by default. Additional components can be created with a hardware definition language such as Verilog, or by using Quartus' "MegaWizard Plug In Manager" to configure and insert a variant of an IP core. I set my project up for the Cyclone II FPGA as I have used it for previous projects. To simulate the 74HCT165 shift register I configured a variant of the LPM_SHIFTREG IP core with 8 bits of data, parallel inputs and serial inputs, serial output, and a clock enable pin.

Unfortunately this still does not quite match the 74HCT165 exactly as it has D flip flops rather than transparent latches. I could build my own shift register in Verilog, but to save time I opted to stick with the LPM_SHIFTREG version and ensure that the timings seen in simulation were such that the transparent latches wouldn't cause a problem.

In order to test the design I set Quartus up to launch ModelSim and run Gate Level Simulation after compilation. ModelSim can be driven manually through the GUI, but this is fairly fiddly and repetitive. Fortunately it supports scripting via 'do files' which contain lists of commands for ModelSim to interpret.

I set up four do files:

init.do - Reset, add graphs for appropriate signals, set default values for inputs
shift8.do - Drive the data bus to the appropriate values to set SHIFT8 and deassert /BITBANG, then assert and deassert /CONFIGWR
write.do - Simulate a write to the device by driving the data bus and /DATAWR signals, zoom graph to fit
sdtest.do - Run the previous three do files in sequence, zoom graph to fit

This allowed a fairly quick turnaround by hitting compile in Quartus, selecting the project once ModelSim launches, then typing 'do sdtest.do' to run the simulation.

For a different project I could have sped things up by keeping everything inside ModelSim, but this would have required me to design the circuit in a hardware definition language. Since my final target is a circuit built from discrete components and not an FPGA bitstream I decided to take advantage of the Block Diagram/Schematic feature in Quartus. This way everything could be easily translated back to a physical circuit once it was verified as working.

Now I have the autoshift circuit working, theoretically, I just need to find some time to build and test the physical version!

Retrochallenge 2016/10 - Previous version and problems

2016-10-15T13:51:00+01:00

In my previous post I promised to show the previous implementation of my Z80 SD interface, and to run through the problems which I intend to fix this month.

The 74138 (U1) in the top left of the schematic is used to detect and decode IO reads and writes from the Z80. Three bits of the address bus (A7, A1, A0) are decoded along with the /RD line, M1 line and /IORQ line. With this configuration the device responds to any IO address between 0x80 and 0xff. Some more gates will be used to further decode the address later. The lower two bits (ie. the address modulo 4) select a register within the device. Address 0 selects the DATA shift register (U4) for reads or writes while address 1 selects the CONFIG register (U3) for writes only.

One NAND gate from the 7400 (U2A) quad NAND is used to invert the CONFIGWR signal, as the 74138 outputs are active low while the latch input on the 74374 is active high.

In the middle row of the schematic are the 74374 register (U3) that holds configuration information and the 74299 shift register (U4) that is used to transfer data to the SD card. To the right of these is a 74165 (U7) shift register that implements the automatic shifting mechanism for high speed mode along with some more NAND logic (U2B, U2C, U2D) to generate the appropriate signals depending on the operating mode.

The automatic shifting behaviour is implemented by latching the state of the SHIFT8 bit of the config register into all 8 bits of U7's input register when /DATAWR is asserted (ie. the data register is written to). This fills the register with 1s. The serial in (Ds) pin of the register is connected to ground so with each clock pulse the train of 1s is shifted and the gap is filled with a 0. The serial output of the register (SHIFTING) is NANDed with the clock by U2B. The output from U2B is either a train of 8 inverted clock pulses or a constant logic 1 level, depending on the state of SHIFT8 at the time the DATA register was written to. NAND gate U2C will either invert this train of clock pulses if /BITBANG is high, or reflect the inverted state of the /BITBANG config bit if U2A is outputting a constant logic 1 at the time. Put together this allows either the SHIFT8 config bit or the /BITBANG config bit to control the clock depending on the desired operating mode (relying on the driver to avoid trying to do both simultaneously).

The final NAND gate of the 7400 (U2D) is used to invert the /DATAWR signal to drive U4's S1 input to select the Parallel Load operation when /DATAWR is asserted or to Shift Left otherwise. S0 of U4 is tied to ground as the Shift Right and Hold operations are never used.

Finally, a 74107 dual JK flip flop was used to divide the RC2014's clock signal (CLK) by four to produce (Q_CLK). This was initially intended to solve a timing issue, but has caused more trouble than it was worth.

The timing diagram below shows the behaviour of the device when the SHIFT8 bit is set and a write is issued to the DATA address.

A couple of issues are noticeable:

SH_CLK is producing one partial pulse, followed by a gap, followed by 7 real clock pulses.
/DATAWR (and therefore SH_LOAD) is asserted for several clock pulses.
CLK (actually Q_CLK) behaves strangely.

Most of these issues were introduced by attempts to work around other problems.

Before the clock divider was introduced U7 was emitting a train of 11 clock pulses rather than the expected 8. This is because the 74165 has a transparent latch rather than an edge triggered latch. The Z80 asserts /IORQ for many clock cycles so the train of 1s from SHIFT8 was being reloaded, wiping out the 0 introduced through the Ds input, until /IORQ was deasserted. Introducing and resetting the clock divider was an attempt to prevent the shift registers from being clocked during this period by holding it in the reset state when /DATAWR is asserted.

Unfortunately because the Z80 instructions take a variable number of clock cycles to complete and aren't necessarily a multiple of 4 cycles the state of the divided clock when /DATAWR is asserted is not predictable. This is likely the cause of the glitchy short pulse seen on CLK as /DATAWR is asserted.

Without this unexpected pulse U4 would not be loaded, as 74299's the Parallel Load operation is synchronous with the clock, and shares a clock with the Shift operation. Extra logic would be required to create a seperate clock that is a superset of the shift clock.

Given these problems I'm going back to the drawing board slightly. I may try adding the extra logic to clock only the 74299 but if that fails I'm replacing the 74299 with a pair of shift registers - a 74165 for data moving from the Z80 to the SD card and a 74595 for data moving from the SD card to the Z80. This is probably wise anyway as the 74299 is a rare part which is many times the cost of a 74165 or 74595 and supplies are less plentiful.

I'll also be removing the 74107 clock divider circuit and replacing it with a simple edge trigger circuit to limit the /DATAWR pulse to a single clock.

Hopefully I will have a write up of this new version soon.

Retrochallenge 2016/10

2016-10-05T20:04:00+01:00

I decided to join in with ` <http://www.wickensonline.co.uk/retrochallenge-2012sc/>`__Retrochallenge 2016/10 this October. I'm also hoping this will provide some incentive to write more posts and updates about other projects once I'm back into the swing of things!

My goal for this Retrochallenge is to finish an SD card interface I started designing for Spencer Owen's ` <http://rc2014.co.uk/>`__RC2014 Z80 based computer (which was spawned by a previous Retrochallenge, hence the name). This should work with most Z80 computers that don't do anything crazy to the I/O interface, so I may also get it working on a ZX Spectrum if there is time.

I'm intending to build my SD interface from 74 series and similar discrete logic ICs. This is partly for fun and partly because the microcontroller in the SD card is likely already more powerful than the RC2014. Adding another microcontroller into the mix to interface with the one in the SD card is just a step too far.

I'll be using the SPI-like mode of the SD card protocol, not least because information on the faster SD mode is not publicly available. The SPI-like interface should allow me to use shift registers for communication with the SD card.

I was initially planning to use a 74ALS299 universal shift register to reduce chip count. Unfortunately, in addition to being somewhat hard to get, the interface on this chip is troublesome as the shift, shift direction, and output enable are all synchronous and controlled via two pins that set the operation. The extra glue logic needed to deal with this completely nullifies the benefit of using a single universal shift register. Because of this I'm planning to redesign around a pair of shift registers: a 75HCT595 serial-in-parallel-out register and a 75HTC165 parallel-in-serial-out register.

The SD card requires a slow clock pulse for initialisation (around 100khz), but once initialised supports faster clock speeds. The design is complicated by the need to run at both speeds, but I have a scheme to cope with this.

My intended interface uses a pair of registers mapped to the Z80's I/O space.

DATA

Writes to this address latch the byte from the Z80 data bus into the 74HTC165 which is used to send data to the SD card.
Reads from this address enable the outputs on the 74HTC595 shift register which receives data from the SD card.

CONFIG

Writes to this address update a 74HTC374 register holding a configuration byte. The following bits are currently used:

autoshift - Automatically shift 8 bits from the shift registers to the SD card and back after a write to the DATA address. This is used for the SD card's "normal" high speed mode and should allow fast enough I/O that the Z80 becomes the bottleneck.
clock - OR'd with the automatic clock signal to the shift registers and SD card, allowing communication at a speed controlled directly by the Z80 to provide a 'bitbang' mode. This mode is not efficient, but allows the slower speed required for the SD card initialisation process without much extra logic.

An initial version similar to this design has been built on a breadboard using a 74ALS299. In addition to the issues with the synchronous control signals needed to load this shift register, there were also compatibility issues with the timing of the Z80's I/O control signals. This requires additional glue logic and a redesign of automatic shifting logic that enables the high speed mode to work.

Before I take the previous version apart to rebuild, I'll take some logic analyser captures indicating the timing issues, and write up (and remind myself of) the problems.

SpeedTwin Update

2015-08-02T19:59:00+01:00

Recently I've been focussed on finishing off my radio controlled model SpeedTwin ST-2. This guy is not the biggest model I've built in terms of wingspan, but it wins in terms of chunkiness and complexity. I started it in 2012, but it stalled at some point because everything was blocked by scary "one shot or it's ruined" style tasks. I recently dug it out and decided to get these things over with so I could get it back on track.

The fuselage was stalled as the servos and radio receiver needed fitting before any progress could be made, as they would soon be difficult or impossible to access. After fitting the servos I coated a sheet of 1/16th balsa with epoxy and stuck it to another block coated with tape, shiny side out. Once the epoxy was dry the taped sheet was removed leaving a perfectly smooth surface which the receiver could be stuck to with double sided foam tape. I glued this mounting to the side of the fuselage with a few balsa rails so it could be easily removed if necessary but was still securely fitted. This was mounted behind the canopy area in a spot that was still accessible while being as far as possible from interference from the battery and speed controllers. This location also provided a convenient spot to mount the antenna vertically.

With the servos and receiver installed the decking on the rear of the fuselage could be added. This is designed to form a skin over the formers and spine of the fuselage and give it the correct final shape without having to use excessive material or sand material away. To fit this I first figured out the best way to have the grain match the curvature of the surface and cut some 1/16th balsa to shape. After a few test fits this was glued where it meets the fuselage sides and left to dry. It was then curved around the formers and glued a bit at a time to avoid overstressing the material. Despite this a crack formed at the very rear. I was able to fix this by glueing and pinning it in place and sanding it smooth later. Once this was glued on I cut the sheeting down the centreline and repeated the process for the second half.

[gallery ids="876,890,892"]

With the rear of the fuselage essentially finished I moved on to the front end. The nose was built up from blocks of 1/2 and 1/4 inch balsa which were glued on and then sanded to shape. This process requires a lot of sanding allows for nice curves to be shaped easily. The canopy was built in a similar way but from a block of blue foam glued to a balsa base. The foam was shaped to the correct profile with my hot wire cutter and then sanded the rest of the way. A 1/64th ply windscreen section finishes it off. The canopy base has some rails glued to the bottom which locate into the opening on the fuselage. The canopy is then held in place with a dowel at the back and will eventually have a catch installed at the front.

[gallery ids="878,838,842"]

At this point the fuselage was basically finished except for the covering. I decided to use a lightweight fibreglass technique for this with 25gsm glass cloth and water based polyurethane instead of epoxy resin. An internet search will provide plenty of good instructions on this process so I won't expand upon it here.

With the fuselage out of the way there still remained a lot of work to be done on the wing.

First the leading edge of the wing (formed from a strip of pre-shaped balsa) was glued on to the front of the wing and sanded to match the wing's taper. With this in place I was able to locate the wing in the fuselage and measure from the tips to the rear of the model. Once these measurements and the measurement from each wingtip to the fuselage matched I was convinced the wing was aligned correctly. I drilled a hole for a locating dowel into the front of the wing through a hole in one of the formers and another hole through the wing so it can be held in place by a nylon bolt. The dowel and bolt will provide a secure and repeatable fit for the wing (but hopefully the nylon bolt will break instead of the wing in the event of a crash).

The next part of the wing that needed attention was the engine nacelles. The original has huge engines hidden inside bulbous nacelles which needed to be recreated (even though my motors are relatively tiny). I chose to use the designer's recommended method for this which is to plank the nacelles by glueing strips of wood over formers, with some foam parts where the curvature made this impractical. I decided to build these in two parts with the upper part permanently attached and the lower part removable in case access to the landing gear mounting points was needed later.

[gallery ids="881,884,885,886,859,867,866,865,848,840,851"]

During this process I ended up making a second hot wire cutter for making parts that needed square edges (at least before sanding) and for parts that needed a consistent thickness. This consisted of a frame made from an old speaker cabinet with a hole drilled in the centre. A screw inside the hole mounts the bottom of the hot wire which runs to a similar hole at the top. The top of the wire is mounted to a spring (for tension) attached to a block which can be moved about and clamped in place. Spacers under the block that holds the top of the wire allow adjustment of the sprint tension. A thin strip of wood attached to the table with a smooth shank screw makes a fence which can be clamped in place to cut parts to a consistent thickness.

The planking was slow and tedious but performed in short bursts - adding a few strips and leaving the glue to cure while doing something else. Unfortunately I wanted to build the upper nacelles first, so the removable section could be built to fit them. I learnt partway through that using softer wood was better for this process and the lower nacelles came out nice and smooth with just sanding. The upper nacelles made from harder balsa required quite a bit of filler and some reinforcement from beneath to get them nice and smooth.

[gallery ids="872,870,861"]

My motors will fit on the front of the part of the nacelles shown above, with an extra bit of foam that will be sanded to shape to hide the motor and provide a nicely shaped front section to the nacelle.

Once the nacelles were built I installed the landing gear struts using some P shaped clips made from brass. These were made by folding brass strip around the landing gear wire using a vice, drilling a hole in the correct place then trimming them to size. This allowed the struts to be bolted to plates attached to the underside of the wing. A hole had to be cut into the lower nacelles in a suitable place for the strut to fit through, with some clearance to avoid damage if/when the wire flexes. Cutting these holes was a bit nerve wracking after spending so much time on the nacelles, but after measuring several times I was able to hit the correct location first time (with some extension of the holes to fine tune the fit).

Finally the wing tips were cut from from blocks of balsa, roughly shaped and then attached and sanded to their final shape.

Once the wing was complete I did several passes to check for dents and other issues (which were fixed up with filler) before glassing it in the same way as the fuselage. The nacelles were glassed first followed by the rest of the wing, with cut outs around the upper nacelle area to avoid the extra curvature causing problems.

Glassing the fuselage added about 30g to the fuselage (which originally weighed about 235g) and 50g to the wing, which originally weighed about 495g. This is not a problem and well worth it for a sturdy finish. As the numbers show, most of the weight and complexity of this model is in the wing since it's a twin engine design.

This brings the project pretty much up to date, and all that remains is the last 10% which will probably take 90% of the time!

CNC cut control horns

2015-05-04T19:35:00+01:00

I was at a loose end during today's bank holiday so I decided to do a mini-project (with bonus recycling features) and make a set of control horns for my radio controlled SpeedTwin ST-2.

After deciding on a sensible size for the control horns I drew them up in DraftSight. These ended up being 25mm tall and 12.5mm wide at the base. I designed them on a sprue so that when I come to etch the remaining copper off they don't get lost in the etching tank. The horns are shaped so that the holes for the linkage can lie on the hinge line with plenty of material around them for strength.

The DraftSight file for the parts can be found on GitHub in my rc-parts repository, which also contains drawings of various bits of radio control hardware that I've designed parts around. Please feel free to use any of it or to contribute drawings of parts.

The PCB material I used comes from a nice FR4 board onto which was otherwise unusable due to a design mistake. The board was intended to be used as a 2 player version of Charlie's 'Minigun' miniature SuperGun project. Unfortunately after etching I noticed I had messed up the pinout of the JAMMA connector when transcribing the design from Eagle to KiCad. Rather than throwing it away this project is allowing me to reuse the material for something useful. My 2 player 'MiniGun' will eventually get finished and written up too.

As a quick aside, the SpeedTwin has made some progress since I last posted about it. The fuselage is nearly finished, except for sanding the canopy to shape and some more work on shaping the nose cone. The wing is also coming along, with the top half of the engine nacelles planked and mostly sanded to shape. The remaining work on the wing is to install the tips and build the bottom half of the nacelles, which will be removable for access to the landing gear.

Once the control horn design was ready I used CamBam to convert it to G-Code. Unfortunately some manual editing was required on the output to get Grbl to accept it happily. The main problem was a G17 code, intended to signal that arcs should occur on the XY plane, which caused Grbl to error after any subsequent G3 (arc) code. This setting was default anyway so the line was removed with no adverse effects. I also tend to remove comments from any code that is passed to Grbl - the parser can choke on lines over 50 characters so comments at the end of lines are best removed. If I find an open source CAM program that will provide Grbl compatible G-Code out of the box I will probably switch to it, I just need to put in the time to find one. :)

This is the first time using my eShapeOko since I rebuilt the controller so I had to spend some time setting up again. Once I'd calculated the appropriate steps/mm settings for each axis everything went fairly smoothly and after a few 'air cut' test runs I cut the parts. Since this part is all made in one cut I simplified things slightly by removing all of the Z axis movement from the program. I manually plunged the bit into the work from GrblController and then set the program going.

I decided not to drill the holes on the CNC to save setup time and because I don't have a suitable drill bit that fits my eShapeOko's rotary tool. They will be quick and easy to drill accurately on the drill press at NottingHack at a later date.

All that remains is to etch the remaining copper off (and sadly lose the current futuristic look), drill the holes and cut off the sprue.

Hot Wire Cutter

2015-03-15T21:58:00+00:00

While building my model SpeedTwin ST2 I needed to neatly cut some foam. Since I had a bunch of 6mm laser safe ply available and needed to cut some other bits the next day I decided to design my own hot wire cutter and cut the parts out at the same time.

The cutter is designed to be built around some 1/2inch spruce engine bearer stock that I had lying around. Any roughly 1/2inch square section wood will work so long as it is stiff enough.

Most of the parts are designed to be built from 6mm ply, with a few 3mm bits. 6mm, 3mm and 2mm bolts are used to attach the fittings to the wood. Some nichrome wire is used as the heating element, with some stiff wire on the other side to tension the cutting wire. I added some springs to help maintain the tension as the wire stretches. These would work better on the other side to that shown in the photos to increase the amount of wire available for cutting.

I've found lots of articles online about DIY hot wire cutters that suggest using a transformer connected directly to mains, with no current limiting or anything. DO NOT DO THIS. Those people are idiots (and they're most likely in a country with a lower mains voltage). I've been running my hot wire from a lab power supply in current limited mode and it works nicely and gives excellent control over the temperature of the wire.

I've uploaded the DraftSight files to my GitHub account for anyone who is interested in them, but please bear in mind the finished product could be dangerous and I take no responsibility for what you do with it.

Foobot

2015-03-15T21:25:00+00:00

Foobot is a project I started around November 2014. It's still a work in progress, but the time when I should have written it up is more than due.

Foobot is robot table football game, with two teams of two tiny adorable robots. The robots are controlled by classic Nintendo and Sega controllers, hopefully it can can finally settle the age old console wars. :)

The intention eventually is to build some games around these robots. Possibly with the ability for a computer to control some of the robots via some image processing if I'm feeling really ambitious.

The robots are built around an ATtiny2313 microcontroller, with an SN754410 to control the motors and a cheap 1402 433mhz radio receiver module. This is mounted on a simple laser cut perspex frame with two wheels mounted directly onto the motors.

The initial design was built on stripboard, but once I had it working I ordered a professionally made PCB via http://dirtypcbs.com/. This was the first PCB I've had made and the quality turned out to be better than expected for the price and the 3 week shipping was pretty bearable.

As the radio modules are very simple (and one way) I decided to avoid the problem of collisions between multiple transmitters by attaching the controllers for all players to a single radio transmitter. The transmitter reads all of the controllers and then sends a packet addressed to each robot in turn. Messages for the robots consist of a robot ID, the message payload and a checksum. Robots ignore all messages not addressed to them and any messages with invalid checksums. Dropped packets or interference are dealt with by hoping the next message with more up to date data will arrive.

The transmitter module is based around a tiny 8 pin ATtiny13 microcontroller. This has just enough pins to read data from all of the controllers and to send a signal to the transmitter module. Some of the lines are shared with the In-Circuit Programming interface for the microcontroller - these were chosen to be the outputs so there was no need to worry about other hardware interfering with programming.

In order to read 4 controllers with 4 pins the transmitter uses a pair of controller interface boards. These have a socket for a NES controller (which contains a shift register so the button states can be read out serially) and a 74LS165 shift register which enables the Master System controller to behave like a NES controller (it is just 6 buttons with a shared common pin). The 75LS165's latch line is inverted so a transistor was required to invert this in order for the same latch signal to operate both devices.

With this setup the only extra pins required on the microcontroller are shared latch and clock signals and a data line for each NES/Master System controller pair. The serial output from the NES shift register is passed into the serial input on the 74LS165 so sending a latch and 15 pulses reads 8 buttons (2 unused) from the Master System controller and then 8 buttons from the NES controller. The Master System buttons are mapped so they come out in the same order as the buttons with equivalent functions on the NES controller (A, B, Select, Start, Up, Down, Left, Right and 2, 1, N/A, N/A, Up, Down, Left, Right).

In the case of the transmitter the circuit was initially tested on a breadboard. This proved quite fragile due to the flying leads to the various controllers so I ordered some more custom boards. The price break on DirtyPCBs is at 5x5cm, so I designed a single board containing the controller interface and a board to carry the microcontroller in a single 5x5 square. I designed tabs into the board outline to allow the two boards to be broken apart. When fully assembled the transmitter contains two of the controller interface board and one of the microcontroller board, so there will be some spares of the smaller board. The cheapest quantity from DirtyPCB is a protopack of 9-12 boards (I got 11 both times), but I only need one transmitter currently so that works out just fine.

I struggled to motors that are both cheap and small without a ridiculously high RPM. The motors I settled on in the end run at around 16000 RPM and 9 volts. Because of this I had to add some code to pulse width modulate the enable pin on the motor controller. Turning requires very little force so it runs with a very low duty cycle. When moving forward initially the motors run at full power to get the robot moving, after a short delay the duty cycle is lowered to avoid accelerating too fast.

Tuning the PWM settings has proven fiddly, and testing with the programmer attached is almost useless as the wires affect the motion of the robot too much. Because of this I implemented an over the air update of the PWM settings. This added some extra commands to update the PWM duty cycles over the radio, and a command to write the to the microcontroller's EEPROM to save them permanently once the behaviour feels right.

I've uploaded the project to github, including all of the code, schematics, PCB layouts and chassis/case CAD files. Feel free to use these, but please bear in mind that the project is still a work in progress.

Finally, here's a video of some Foobots in action (before the over the air PWM tuning feature went in):

Tricopter

2014-12-28T16:12:00+00:00

I've been neglecting this blog recently due to various distractions but have several projects I want to write up. Around April I found myself with the urge to build a multicopter. In the end I settled on a tricopter design as it's a little unusual and because the wider angle between the arms allows plenty of clearance to mount a camera without getting the propellors in frame.

To keep costs down and because I enjoy designing things I ended up drawing and laser cutting my own plywood frame. This was loosely based on the folding arms of David Windestål's design, with a lot of modifications to fit the size and shape I wanted and to fit the parts I had chosen.

The arms of my tricopter are cut from 3/8" birch engine bearer stock, as sold in most model shops. I bought 3 12" lengths which I cut off centre to make a set of 7" arms and a set of 5" arms. In the end I was happy with the 7" arms so I've not yet tested the 5" version.

The frame is designed to have two 3mm ply lower plates that the arms are sandwiched between, held together with 2mm machine screws. The screws are tightened so that the arms are held in place by friction when unfolded, but they can still be folded relatively easily without any adjustments or tools.

Following David's pattern, the landing struts and motor plates are attached with cable ties. These hold everything firmly in place but will hopefully give or break before the frame components if too large an impact is applied.

Above the two structural plates of the frame there is a third plate with a large number of cutouts. This sits above the frame on laser cut plywood standoffs and serves to protect the electronics that sit on top of the frame. The KK 2.1 flight controller I'm using has a build in LCD display and buttons for configuration in the field. All of the buttons and the display are accessible through a cutout in the top plate. Additionally the plate helps with cable management, wiring being attached to the frame with cable ties and velcro straps to keep it neat.

Because I went for a tricopter design I required a swivel mount for the rear motor. This consists of a modified motor mount plate with two tabs on the bottom through which an M3 bolt is threaded. A pair of bearing carriers are formed from two layers of ply parts that slot over the rear arm with appropriately sized holes to trap a pair of bearings through which the bolt runs. The rear landing strut was cut with an appropriate cutout for the metal gear servo that moves the rear motor mount. This turned out to be a weak point and is so far the only part I have broken. A new design has been drawn up but has yet to be tried as the replacement rear leg is still going strong after many more landings (with slightly more care).

Electronically the tricopter is fairly simple, though there is a small hack to power the rear servo. Each speed controller includes a voltage regulator which normally powers the other equipment that needs 5 volts. Since there are multiple ESCs in a multicopter, only one of these is required. People cut the 5v wire to prevent the regulators from fighting (probably only necessary with switching regulators). The KK 2.1 board simplifies this as the first ESC connector powers the board and radio reciever while the 5v pin from the other 7 are isolated so no wires need to be cut. This does mean, however, that no power is provided to the servo. To work around this I modified the rear ESC by desoldering the 5v wire and removing it from the connector. I then soldered a 3 pin header to the voltage regulator output to make the 5v and ground lines of an additional connector. The 5v wire from the original connector was attached to the third pin of this and at the other end plugged into the signal pin from the servo output on the KK 2.1 board. This provides a connector on the rear ESC into which the servo could be plugged, providing power and the appropriate signal to drive the servo (see diagram).

Very few changes were required to make the tricopter fly nicely, with the exception of increasing the proportional gain for roll and pitch without which the controls felt quite sluggish.

I have some video from an early test flight shot using a cheap 808 keychain camera. I've since bought a Mobius and added an appropriate mount but haven't had chance to get any footage with the new camera due to weather. The downside of building the tricopter from wood is I don't want to get it wet!

Components:
Reciever: Hitec Optima 7
Flight Controller: KK 2.1
ESCs: Turnigy Plush 10A
Motors: Turnigy Multistar 1704-1900kV
Rear Servo: Turnigy TSS 10-MG
Battery: Turnigy 1000Mah 3S 20C LiPo

I've made the drawings from which the tricopter was built are available to download and I'd enjoy hearing about it if anyone uses them in a project.

eShapeOko Part 3 - Tidying up

2014-09-13T22:53:00+01:00

Having had the ShapeOko for over a year now I've used it for quite a few projects, but nowhere near as many as I intended. Part of the reason for this is that the controller for the machine was still rather jury rigged so setting it up was a hassle. To solve this problem I've been working on integrating together a permanent version of the controller.

I started by designing a pair of custom PCBs with a bus to connect them together while allowing for expansion. The first board is essentially an Arduino with custom pin out. The second board mounts the stepper controllers. At some point I may add a breakout board for limit switches and a board to interface with a pendant for manually controlling the machine.

Having built the boards, they all work fine, but there are things I'd do differently if I made another. First off I'd probably stick with a standard Arduino pinout, both for reusability and because the 24 pin DIL socket I used turned out to be expensive. Additionally, the layout for the (single sided) boards would have been much simpler without the DIL socket to consider.

With the boards made I decided on using an FTDI module I had lying around for USB to serial conversion, replacing the Minimus that I was using previously. I designed a very simple breakout for this module to expose the Power, Reset, Ground and Serial Tx/Rx signals in a way that matches the Arduino's FTDI header. The main benefit of the breakout board, however, was that I could give it appropriate dimensions for mounting in a case.

With all of the boards made and (a few months later, once a burst of motivation turned up) assembled, I needed to build a case to keep the parts together. I decided to laser cut the case from perspex in order to get it made quickly and because I thought a clear perspex case would look cool.

Due to my earlier experiences with fried Stepper Controllers I decided to use locking connectors to prevent accidental disconnection while the machine was powered up. After some searching I found that 4 pin gx16 aviation connectors seemed to do what I want. I ended up ordering some from China through Amazon as it was the cheapest source, though thanks to the seller incorrectly filling in the customs form I paid more than expected for them. Regardless, they work nicely and look good. I also used one of these connectors for power, with two pins acting as 12v and ground and spare pins for signalling. Should I choose to power the machine from a PC power supply at a later date, one of these lines will be used for the PSU's power on line.

With the connectors and some switches chosen and measured, I began work on designing the case. I settled on a fairly simple tabbed box design. The box is split into two sections to match the two widths of board: narrow USB to serial breakout and wide Arduino and Stepper Controller boards. The sides of the box have slots into which various mounting plates can be bolted. The boards locate into slots in the mounting plates, allowing for quite flexible arrangement of the boards.

With the case parts cut, I found it fairly fiddly to assemble, but once together it was quite sturdy. Some of the wires to the connectors had to be soldered with parts of the case in place. This makes maintenance slightly trickier, but will reduce the chance of intermittent connections to the steppers which could exist if I'd used a second set of connectors on the board.

The layout of the connectors and switches was mostly determined by the shape of the case and the space taken up by the boards. I ended up with the stepper connectors on the top of the case in the same section as the USB to serial adapter. The connectors are quite deep, so they required a lot of space behind their mounting plate.

On one end of the case there is a cutout for the USB to serial board and a reset switch for the Arduino in the form of a big red button. It's not exactly an emergency stop button but should have a similar effect.

On the other end is an extra gx16 connector for power and a switch that will act as a power switch if a PC PSU is used. The switch is designed to connect or disconnect the ATX PS_ON line instead of being directly in line with the 12 volt input, which would require a sturdier switch. There is space for mounting a much smaller alternative switch, but I went with a large toggle in the end.

Each end of the case has a grille and mounting holes for a 45mm fan should extra cooling be required.

In order to keep the cables for the steppers tidy, I slipped on two pieces of heat shrink over the paracord sheaths I added. These keep the ends of the paracord neat at each end of the cable and provide a bit more bulk so the strain relief in the connectors has something to grip.

Simple PCB drilling jig

2014-06-12T21:16:00+01:00

Recently I've been making a lot of printed circuit boards. One of the common problems I run into is aligning holes correctly when hand drilling. This is especially troublesome on boards with large arrays of pins, such as my hexapod controller (I promise I'll write that up soon!). A misaligned hole will prevent IC sockets from fitting correctly or cause pin headers to sit at crazy angles. This is really obvious on the first version of my hexapod controller board as shown below.

In order to work around this for the second version of the hexapod board I used my CNC machine to drill the holes. This is great for relatively large jobs, but the setup time makes it less attractive for small one off boards.

Since I was scheduled to have an induction on Nottingham Hackspace's new laser cutter and given the option of cutting my own project during the induction, I came up with a simple mechanical solution to drilling holes at the 0.1 inch spacing required for most IC sockets and pin headers.

The concept is very simple: a zigzag line is cut through a piece of plywood with a "wavelength" of 0.1 inches. One side of the cut is clamped to the work surface of a pillar dril,l and the board to be drilled is taped to the other side. The serrated edges can be moved around, and when pushed back together they naturally align to multiples of 0.1 inch. I went with a sawtooth style wave in the end so pressure can be applied in towards the flat edge of the sawtooth without the piece slipping.

The photo above shows masking tape, but double sided tape would have worked better if I'd had any with me when taking the photos.

In order to make grid style layouts I added a second layer of serrations at 90 degrees to the first. I've not had chance to test this as the work area of the pillar drill I've been using does not have space. The intended usage is that both of the outer stages would be clamped in place and the inner piece manipulated by hand to drill columns of holes. Once a column is complete the middle stage would be un-clamped, adjusted then re-clamped. This is repeated for as many columns as necessary.

I've used the jig with a single stage on a few boards now, and it works well so long as the initial hole is well aligned. An easy way to ensure this is to align the drill bit with the smallest hole in the row and then clamp the jig in place.

To ensure that the board is aligned correctly in the jig, I usually find the longest run of holes on the board and put a ruler against the edge. Drawing a pencil line along the ruler provides alignment marks on the board that can be matched up with the etched lines on the jig.

In the current version, the inner section of the jig is a sacrificial piece which will eventually become full of holes. I toyed with the idea of making the inner section in an L shape into which the board would fit, but this would rely on the edges of the board being cut exactly parallel with the grid so it's less useful in practice. Hopefully the sacrificial part of the jig will last long enough, and it's cheap enough to just make another when it wears out.

Earlier today I used the jig to make a very simple breakout board to match the pinout from an FTDI board to an Arduino style six pin header. The 6 pin header and 32 pin (minus 4 due to the weird layout on the FTDI board) IC socket I used fitted perfectly first time.

I've made the CAD drawing for the jig available to download. Hopefully it will be useful to someone.

DrillingGuide.zip

Arcade Control Panels

2014-02-17T23:20:00+00:00

Charlie's SuperGun had me inspired to build my own at some point, but I thought I'd start at the other end and build some appropriate controllers first. Partly as a birthday present to myself I decided to make a pair of arcade control panels.

After a long time reading SlagCoin, I settled upon a fairly simple box design with a joystick and 6 buttons on the front face and a pair of buttons on the left and right. I eventually settled on a black and white theme, with a black Perspex face plate and white buttons.

To get started, I ordered two sets of joystick + 8 arcade buttons from UltraCabs. I also bought a pack of 100 4.8mm female spade connectors, 20m of stranded wire and two A4 sheets of black Perspex from eBay.

Once this arrived I was slightly overwhelmed, but also motivated by the need to get it all off of my desk so I could reclaim some space.

To decide on the final layout, I printed out various button layouts and experimented to see what felt best, how much space was required for wrist rests and how much separation was needed between the joysticks and buttons. I settled on A4 size for the main panel as this provided plenty of wrist support and neatly avoided the need to trim the Perspex sheets I had.

With the panel layout decided, I wanted to get an idea of how the controllers should fit together and ensure everything would fit. To achieve this I measured and drew the joysticks and buttons in Draftsight before designing the rest of the structure around them. From the initial 3-view I had drawn, I extracted the various panels and printed these for reference during the build.

You can download the drawing from here, but bear in mind other brands of buttons and joysticks will vary in size: Arcade Controller Layout

For the cosmetic front panels I used the Nottinghack laser cutter to cut holes for the buttons, directly exported from my plan. Later on, the front panels also provided a template for drilling the structural front panel accurately.

For the box I wanted to hide any visible screws, so I built an inner frame that supported most of the structure from some wood reclaimed from an old sofa. Each pair of sides was match cut by taping two pieces together and cutting them to length on the chop saw. They were screwed together and countersunk using framing clamps to keep everything square, ensuring that everything lay flat on the table after each corner was joined.

With the inner frame built, I made a nice looking outer frame from some planed timber which happened to come in the required size (70mm wide, 18mm deep in my case). I match cut the parts for this similarly to the inner frame, then screwed this onto the outer frame through pilot holes drilled in the inner. I wanted the Perspex front panel to sit slightly proud of the top of the outer frame. To ensure that everything aligned nicely, I used the real Perspex front panel and some material slightly thinner than the structural front panel to pack the inner frame to the correct height. With the outer frame sitting on the table surface. Once a pair of sides was attached, the packing material was removed so the real outer frame could set the correct alignment for the other two sides. Once the outer frame was attached, I drilled a hole in the back of the the outer frame about 1cm from the bottom for the USB cables to exit, then used a saw to extend this hole into a slot.

Unfortunately, I messed up the placement of the holes for the side buttons while making the outer panels, so drilling the holes in the inner frame would have required drilling through some screws. I decided to leave them out for now and revisit later, I'm planning to make additional changes to the controllers in the future.

With the sides of the box built, I cut the structural front panel from some chipboard plinth material I had lying around from a DIY project. This was made in two parts in my case though this isn't strictly necessary. Once cut to shape this material was fitted into the frame and drilled and counter sunk so that the Perspex front panel could sit on top. With the Perspex front panel in place, I drew around the holes, marking the location of the buttons and joystick. I then took the joystick mounting plate, aligned it with the joystick hole on this panel and traced the outline.

For the button holes I found the centres using a paper template printed from my CAD drawing, then drilled them out with a 1 inch spade bit. For the buttons I used, the hole in the perspex needed to be larger than the hole in the front panel as there is a 3mm deep step below the bevel. Mounting the joystick was more complicated, as it needs to sit as close to the Perspex front panel as possible. To achieve this I used my eShapeOko CNC machine with a 3mm end mill. I had a simple python script that I'd previously written to level the bed on the machine, which I used to generate g-code for the rectangular pockets required.

[gallery ids="652,656,657,658,662,665"]

After routing the pockets and cutting out a square hole for the joystick body with a coping saw I noticed that the body was slightly too shallow, so fitting the joystick would put a lot of pressure on the contacts of its microswitches. To work around this I made some additional pockets on the back side as a relief for these contacts to sit in.

With all the mounting holes cut out I removed the structural front panel and spray painted it black, to blend it in with the Perspex faceplate and to hide all the marks from cutting it to shape.

[gallery ids="645,667"]

To protect the wood of the outer frame, which will be handled often, I painted on two coats of Eze-Cote water based polyurethane resin, sanding in between with 400 grit sandpaper. This is really intended for applying fibreglass to model aircraft, but worked well to give a nice smooth feel to the controllers while retaining the natural look and light colour of the wood.

The final structural component of the controllers was the bottom panel, for which I used a simple A4 sheet of 3mm MDF. This was drilled and countersunk in the four corners and then screwed to the bottom of the inner frame.

Initially I decided I wanted these controllers to be able to emulate a USB keyboard so they could be used on nearly any PC game. Later on I plan to make the encoder swappable so the controllers can be used with a SuperGun or various retro consoles by swapping out an encoder cartridge.

For the USB version I used a Minimus AVR dev board from the Nottinghack vending machine, running a modifed version of the LUFA keyboard demo. I decided since I would be changing the encoder later that I would avoid soldering directly to the Minimus board, so I added pin headers to it. I based the wiring loom for the controller on a piece of stripboard, using a widened 40 pin DIL socket to mount the Minimus. In the case of my controller, all of the ground connections are wired to the ground pin on the Minimus, and the other pole on each microswitch is connected to a pin on either port B or port D of the Minimus.

[gallery ids="620,622,625,674"]

To cut down on the number of wires leaving the board I daisy chained the ground connections for the joystick (4 terminals) and the face buttons (6 terminals). The buttons for the currently unused side buttons (which have their own grounds) are tied back out of the way and covered in insulating tape (not shown above).

You can find my changes to the LUFA Keyboard demo on my GitHub account, but your mileage may vary and I will probably be making further refinements later. Using this code the input pins, mappings and intended uses are as follows:

`` PB0 - Z - Coin PB1 - X - Start PB2 - W - Up PB3 - S - Down PB4 - A - Left PB5 - D - Right PB6 - F - Button 1 PB7 - G - Button 2 PD0 - H - Button 3 PD1 - V - Button 4 PD2 - B - Button 5 PD3 - N - Button 6``

This layout maps the joystick to appropriate keys for playing Nidhogg. Most games will provide some form of input remapping, which is easier than reprogramming the controllers each time. For games where this is not possible, I use AutoHotKey which can remap keys on the fly. More interestingly, it can change the mappings depending on which window is active. For example, to feed my SuperCrateBox addiction, I use the following script:

`` ; ArcadeStick -> SuperCrateBox #IfWinActive ahk_class TRunnerForm w::Up s::Down a::Left d::Right f::x g::z h::p v::z b::x n::Esc #IfWinActive``

Finally, the finished product, fully assembled:

The Perspex panel is held down by the bevels on the buttons, so no additional work was required to fix it.

I still have a few things I need to tackle, but I'm enjoying the controllers as they are currently, and they work nicely on the games I've tried so far.

My future goals for the controllers are:

Input debouncing - hard to tell if this is needed but there is the occasional glitch
Side buttons
Use side buttons to switch between player 1/2 key mappings or as coin/start buttons on a Jamma arcade board
Swappable encoder cartridges
Make use of the illuminated buttons

The Draftsight drawing of the controller is available to download via the following link: Arcade Controller Drawings This contains 2D projections of the wooden and perspex parts needed to build the controller.

Loot of the Forest

2013-12-15T23:18:00+00:00

I just finished participating in the 28th Ludum Dare game jam. This time around the theme was 'You Only Get One'.

I chose to interpret this fairly literally as a game mechanic and came up with Loot of the Forest. It's a game about bribing forest guardian creatures as you make your way through their forest maze, but you only have a single item per species of guardian.

Expect puzzles and weird animal based puns.

Play it here.

The game was written in HTML5/Javascript, with graphics drawn in GIMP, and sound effects generated by the awesome ` <http://www.bfxr.net/>`__. It was fueled by sleep deprivation and cold pizza.

STOMP STOMP STOMP STOMP

2013-12-12T21:21:00+00:00

I've been a bit quiet on here for a while, and slacking on the PCB milling experiments I've been meaning to do, though I have made some progress on that front.

Anyway, here's what I got sidetracked by building:

This is a small budget hexapod, using 18 of the cheapest servos I could find (£2.50 each). It uses a custom board with a power supply and 3 shift registers to control the servos. This in turn is controlled through an SPI bus to a Minimus USB AVR board, pretending to be a USB to serial device. The data sent over the serial line is interpreted as servo IDs followed by the desired position of the servo.

The control software I wrote for the hexapod can run on any Linux computer with a USB port. For dev I use a netbook but it also runs nicely on a Raspberry Pi.

The original plan was to use the Raspberry Pi's SPI port to control the servo board directly, unfortunately due to Linux's scheduling not being particularly real time even in real time mode there was a lot of timing jitter leading to real life servo jitter. Switching to the Minimus meant having a very dedicated if much slower CPU generating the pulses resulting in much smoother control of the servos.

I'll hopefully post a full making of post on the hexapod soon, but for now I just wanted to post a video of some stomping!

The Minigun (A mini Super Gun)

2013-11-24T14:54:00+00:00

Guest post by Charlie again as he continues his quest to take over Moop's blog with his super long posts:

TL;DR?

Then here's a video instead...

http://youtu.be/AGSSvxihYZs

Preamble

Recently I got into arcade boards. They can be found reasonably cheaply on eBay and as most use the standard JAMMA connection, setting these up so you can play them on a TV at home is pretty straight forward. Especially in Europe where SCART is still widely used and thus almost all TVs have an RGB input.

I built a very traditional supergun (device that allows you to play JAMMA boards on a TV) last year. It was time consuming but it wasn't particularly hard. It used a PC ATX power supply to supply the voltages needed (-5V, +5V and 12V), audio/video output was via SCART and Neo Geo AES pin compatible D-SUB 15 plugs for the controller inputs. Here's a couple of pictures of my first effort...

Once I started getting more boards, I found that some bootlegs drew a heck of a lot of current. So much so that the voltage drop over the half a meter or so of wiring between the PC supply and the board was causing the boards not to power up (due to the voltage drop across the wire). I initially tried solving them by using some wider gauge wire in parallel to feed the board. This worked but for some bootlegs I owned even this wasn't good enough. I was reading as close to 5V as I could get at the connector but measuring the voltage on distant parts of the board, the voltage had dropped to sub 5V. I needed something better.

I could have got a JAMMA power supply off eBay with a variable voltage output. This was initially tempting but I just couldn't bring myself to use one for safety reasons. On all the ones I saw the mains power was just wired into screw terminals. This is fine as it'd be inside my super gun's case. The thing that worried me was that the outputs were right next to the mains screw terminal. The boards aren't in a cabinet like a traditional arcade, they just lay on top. If the mains lead became loose there is a possibility of the board becoming live. This may sound surprising coming from the person that made his own bluetooth controlled mains plug, it wasn't a risk I wanted to live with.

So, I went looking for a variable DC/DC convertor that could transform a lot of current without needing any active cooling. After some searching I came up with http://docs-europe.electrocomponents.com/webdocs/0eec/0900766b80eec532.pdf. With this I could power the 5V line from the 12V output of the ATX power supply and add a pot to adjust between around 5-6V so even my very power hungry boards would be happy.

With this done I felt I had a reasonable design. Then with Christmas coming around I decided I could make another one for a friend as a present. Building the first one, I wasn't really thinking about the time it took as I built it and tweaked it over a couple of weeks. Even knowing exactly how to build it now, it still took at least 10 hours to actual do it. I made a few improvements along the way but it was a tedious build due to the huge number of wires involved (>100 connections) and all the modifications needed to the case. Also, even with a lot of salvaged parts (the ATX power supply, the SCART plug etc) it also ended up being quite expensive at about £50. A lot of this was due to the case which was quite hard to find as it needed to be tall enough to fit an ATX power supply.

With that out of the way I vowed never to make another supergun again..... but of course I did. I just kept thinking I must be able to make a better one. After trying the toner transfer method for the first time, it got me thinking that I could do away with almost all the wires by just making a supergun PCB.

The design

Starting the design of a supergun PCB, I really wanted to make it as compact as I possibly could while still making it easy and cheap to assemble. One of the ways to do this was to leave out anything superfluous. The JAMMA standard has various service switches but not all need hooking up. COIN1/COIN2 are the coin inputs for adding credits. These are useful to have on the controller so I wired these to the AES controller's select button as this would otherwise not be used by JAMMA boards. SERVICE on every board I own also just gives credits so I left this out. TILT (for detecting people shaking the machine) is rarely hooked up on superguns and I suspect does nothing interesting on 99% of boards. This only leaves TEST which is useful so this got it's own microswitch on the board.

Power was pretty easy. One reason to use an ATX power supply is that it supplies the -5V that the JAMMA specification requires. However, looking at my collection of arcade boards, one 1 (out of around 10) uses the -5V line at all. They were normally just used for older types of audio amplifiers (my one board which does use it works without it but just without sound). I felt fairly comfortable with just leaving the -5V line out all together. This decision along with using the same DC-DC convertor from my original design means the supply only has to be 12V. Many laptop power supplies are 12V, compact, cheap and can supply plenty of current.

The rest of the design mapped quite nicely to the PCB concept. PCB mounted DSUB and SCART connectors are common. How to connect the JAMMA edge connector was slightly more difficult. However, I noted that two standard 1.6mm PCBs stacked on top of each other was almost exactly the tag separation on the rear of the JAMMA connector. I could make a small board that sat on top that could then run the signals for the top back of the connector down onto the bottom board. Both boards I designed to be single sided (for ease of creating at home) although because they sit on top of each other it does effectively make it partially double sided.

The design was quick to knock up in Eagle (maybe too quick as we'll see later) but when I came to lay it out I hit my first snag. The free version of Eagle is restricted by the size of the board it will let you lay out. The longest dimension is 10cm. This wasn't long enough to connect to every pin of the JAMMA connector. In fact, it was 3 pins short. Luckily of these three, one is unconnected and the last two are ground which exists on the other side of the connector anyway. It would have been nice to connect these additional grounds but I didn't see much harm in leaving them floating (assuming the grounds are connected on the arcade board itself). So I designed the board to the Eagle limitations and just added terminals at that end of the board if in the future I wanted to wire the extra grounds in with some short jumper wires.

Laying out the board itself was straight forward but time consuming as I wanted to keep the layout single sided (with no jumpers) as it needed to be simple to etch at home using hobbyist processes like the toner transfer method. As such I needed to keep the traces fat too. This led to another compromise. Because the traces had to be fat and single sided fitting two controller ports was just too difficult. It's something I'd like to fix in a future design if I was just going to get it professionally manufactured via PCBcart or similar.

Building

Construction wasn't particularly interesting and was quite straight forward. It was only my second attempt at the toner transfer method but the traces were fat enough that I could fix most problems by hand with just an etch resist pen. It wasn't perfect but I was fairly pleased with the end result.

Soldering the various connectors was quick and painless. The only difficult bit was lining up the top and bottom boards to make the double sided portion. Although because the via pads were quite big the positioning wasn't that critical and any slight alignment problems could be fixed by just adjusting some of the drilling locations.

Once the components were all added, it was ready to test!

Testing

Once everything was assembled I grabbed my male to male SCART cable and immediately realised I had made a mistake. I knew I'd made a mistake as I'd made the exact same one with my friend's supergun. Male to male SCART cables don't map all the pins through one to one. Most do but some are crossed over, so for example the audio output pins on one side go to the audio input pins on the other. And the same for the video signal. D'oh! So, out came the scalpel the offending traces were cut and replaced by bodge wires.

Tried again and this time the game sprang to life, everything was great and then I noticed the colours were off. A quick check on the Neo Geo test menu showed red and blue were reversed! Two mistakes on the same board was quite embarrassing. I know exactly how it happened though as when I tried to fix it, I made the exact same mistake. I initially wired up the RGB pins on the SCART from memory and then checked them before doing the board layout. I saw the mistake at this stage and thought I had corrected it. Everything was connected via named labels in the schematic so I just renamed the label on the pin (say from RED to BLUE). Eagle asked "Do you want to connect RED to BLUE?". Thinking this would then cause all the pins to connect I said no but assumed the rename had worked. Nope, I'd just done nothing. A second, "D'oh!".

So back out came the soldering iron and another set of bodge wires causing the final board to be a messier than I would have liked but everything I have thrown at it has worked so I'm quite pleased with the results. Everything works as well as my big traditional super gun but now it's in a very tiny portable package.

Make your own

I made this as my contribution to the super gun / JAMMA comunity so I've fixed up my board layout (the swapped channel problem etc) and I'm offering it as a download here: Minigun - Final (EAGLE file format). I hope people will build there own, make improvements and share these improved versions with the community.

Nb: The current design has the SCART socket mounts overlapping as the connector I used had a different mounting to the stock one in EAGLE. Also the single top layer trace is the 5V line to the controller port. I don't use this in my home-brew controllers so I left it unconnected but if you did want to use AES controllers you may have to solder a jumper wire between these points.

eShapeOko Part 2 - Mechanicals

2013-10-22T21:01:00+01:00

Building the mechanical parts of the eShapeOko was fairly straightforward, but there are some problems and modifications I made that are worth writing about.

The first task of the assembly was to tap the MakerSlide sections to add a screw thread. This was my first try at tapping anything, but it was less trouble than expected, except for a few trips into town to get a tap and die set and some tapping lubricant.

Once the MakerSlide was tapped, everything else pretty much just bolted together, though it's worth taking the time to think about alignment and get the spacers right early on. Sorting it out later may require taking most of the machine apart again just to gain access. Once built, minor adjustments to the alignment of the rails are less of a problem. The process is to loosen the rails to be aligned, slide the axis that runs on those rails to one extreme, tighten the bolts at that end, then repeat for the other end of the axis.

Another thing to note is that it's worth buying and installing limit switches early, even if you won't wire them up immediately. There's not a lot of space behind their mounting points, so it can be difficult or impossible to get bolts in or to screw on a nut from behind.

When buying the kit I went for the dual X axis and dual Y stepper options; I'd definitely recommend these. The dual X axis adds a second section of MakerSlide to the stepper which provides extra rigidity and prevents the Z axis from twisting about the X axis. The dual Y stepper upgrade provides the necessary parts for mounting a second stepper motor to drive the Y axis. I initially bought this but didn't add the second stepper. I quickly noticed that the undriven side of the Y axis was lagging behind quite dramatically. Adding the second stepper fixed this.

With 4 stepper motors to drive there were initially a lot of wires floating around and waiting to get snagged in a nearby moving part. To help with this I ordered some 15ft of paracord from eBay for a few quid. By removing the inner of the paracord and melting the ends of the outer layer to prevent fraying, you can make a nice sheath to reduce the number of cables and make them more manageable.

[gallery ids="426,458"]

Threading the wires through the paracord was fiddly. The best method I found was to use pieces of the inner to pull the wires through. First thread one piece of the inner back through the outer, tie one end around the first wire, then tie a second piece of inner to the wire in the same place. Fold the wire back on itself to prevent the knots from slipping off, and pull it through. This gives you one wire and one piece of inner threaded through the outer. Untie the inner from the wire and tie the other end to a new wire, then tie another piece of inner to the wire and repeat the process. Do this for all the wires, being careful to not let them slip out and to not lose the end inside the outer. You will probably find that the outer will stretch and shrink in diameter, which can fixed by holding the loose end of the wire and pulling the end of the outer away from it, then manipulating the outer to transfer and balance out the tension. This process is also handy for getting the outer to sit neatly against the stepper motor at the end of the process.

[gallery ids="435,441,445,451,450,452"]

This process requires a lot of patience but produced nice results. Curiously I found that although the second and third wires were quite hard to pull through the fourth tended to be easier. This was probably down to the reduced friction of dragging the wire against more wires and less paracord outer, but it's a good reason not to give up if the third wire seems hard to get through.

Initially I had the machine mounted on some old laminate floor boards, which weren't very stiff. This gave bad results for milling wood and terrible results for milling PCBs. Moving to a sturdy chunk of 3/8" MDF resolved this nicely. I have a sacrificial piece of thinner MDF on top of this as a spoil board to preserve the base itself and to provide more mounting options for materials.

The only real problem I've had with the machine so far is with the Z axis. Unlike the other two axes the motion is transferred to the axis via a leadscrew. The leadscrew passes through a flanged bearing sandwiched between two aluminium plates. The motor is coupled to the leadscrew with a RepRap style (I believe) flexible coupler. Unfortunately the set screw that tightens the coupler to the threaded rod can easily push the rod off centre, causing the shaft to wobble unless some packing or tape is wrapped around the threaded rod. Additionally, the rod is held in place vertically by a nut on either side of the bearing. Depending on the precision with which the nuts were made this also can result in the axis wobbling if the nuts are tightened and the axis floating vertically if the nuts come lose.

[gallery ids="472,473"]

The combination of two sources of wobble in the axis and nuts that can come loose easily makes setting up the Z axis very fiddly and quite time consuming. This is currently the main obstacle I've found that is making PCB milling difficult. I've been able to tune out the wobble relatively effectively, though I worry that it may have damaged the plastic runners for the Z axis. I still need to fix the issue with the nuts coming loose. The options for this that I've come up with so far involve either threadlock or buying a second pair of nuts (it's an Acme thread so common or garden nuts won't do it) but I've yet to commit to or try one of these options.

eShapeOko Part 1

2013-08-27T18:28:00+01:00

I was partway through writing a draft for a post about PCB milling when I realised I hadn't yet written anything about the machine I've been using, so I think it's about time for a post about the eShapeOko CNC machine I built.

I ordered the mechanical kit only, so no motors or electronics were included. To kill time while the much awaited parcel made its way to me, I ordered a pair of EasyDriver stepper controllers and some stepper motors to experiment with. The EasyDriver boards aren't particularly cheap but very easy to use, just supply power, ground, connections to the motor and signals for Step and Direction.

I soldered some pin headers onto the boards to break out all of the pins I needed. With them plugged into a breadboard I could easily experiment with driving them via a Minimus USB microcontroller board. Thanks to the simplicity of the stepper controllers I had it driving the motors nicely within an hour, though unfortunately I shortly after discovered several ways to fry the Allegro A3967 chip that the EasyDriver is based on.

The first mistake was forgetting to power off the boards while unplugging a motor. The controller keeps the coils in the stepper motor energised continuously in order to hold the motor steady. Suddenly removing the load tends to fry the controller. When I make a permanent controller board for the machine, I plan to use locking connectors to avoid absent mindedly unplugging the motors in this way.

The second mistake was playing around with circuit on the breadboard while it was powered up. I accidentally connected the Step input to my 12v supply instead of the regulated 5v output that the EasyDriver provides.

Either way, I now had two unusable EasyDriver boards. Fortunately the A3967 chips are available for about 1/4 of the price of the EasyDriver board, so I was able to order some replacements. Despite being surface mount chips they were relatively easy to replace, with a fine tipped soldering iron. The hardest part being removing the old chips as the solder wicks under the pins. Some brute force was required, but not too much as it is easy to peel up the tracks.

With the stepper controllers proven to work (once refurbished) I ordered an additional board to control the third axis.

The next step was to get something in place to act as a controller. I briefly considered writing my own but decided it would add a lot of work and even more unknowns. After looking around online I decided on GRBL. GRBL is a CNC controller firmware designed to run on an Arduino, and thanks to a conveniently timed workshop at Nottingham Hackspace I had an Arduino board I'd built lying around. GRBL takes instructions in G-Code — which is a fairly standard language for controlling CNC machines — and outputs step and direction pulses.

GRBL is designed to read G-Code through the Arduino's serial port, so a USB to serial converter was required (and was also required to program the Arduino). Fortunately, the trusty Minimus board came to the rescue, along with some instructions provided by Reading Hackspace. With a Minimus acting as a USB to serial adapter, I had the electronics side of the machine in place (albeit cobbled together).

I'll cover the mechanical side of it in another post.

Lightwave RF Mood Controller Hack

2013-08-25T21:46:00+01:00

It's me, Charlie again, continuing with my scheme to take over Moop's blog with nothing but home automation articles.

Readers of this blog will know that I've been playing around with LightwaveRF's home automation stuff a lot recently. Mainly setting up voice control systems for it. One thing that irked me though was that to control the devices across the network requires a £65 ($100) box called the WiFi link (http://www.lightwaverf.co.uk/LighwaveRF-Connect-Home-Automation-Smartphone-Wifi-Link-White.html). This seemed a bit much to me but I shelled out the money as there didn't seem to be any option. However, when someone at work started asking about it, it got me thinking if there could be a cheaper way. Maybe it'd be possible to hack the much cheaper mood controller (http://www.lightwaverf.co.uk/LightwaveRF-Connect-Home-Automation-Hand-Held-Remote-Control-Black.html) to be controlled from a Raspberry Pi (or any cheap microcontroller) directly.

So, I started by cracking open the controller I got free in a 3 bulb bundle. At first there didn't seem to be any screws at all. Peeling back the label revealed one though. Even with the screw removed however, it remained stubbornly in one piece. So, I got my spludger out and worked it into the gap of the case. Working my way around I found tabs that needed releasing.

Once inside, I got my first surprise. There's more buttons on the circuit board then there are on the front of the device. I didn't try these buttons but I am curious to know what they are there for.

Next nice surprise was that the switch electronics were very simple for the buttons I wanted to hack (the on/off and device select slider). All three controls clearly weren't multiplexed as they all shared the battery's ground. This made the hack a heck of a lot easier. Next up was checking with a multimeter that the other terminals of the buttons were pulled high. Checking the on and off buttons showed 3V, which is close enough to drive from the Pi's 3.3V logic. The slider however, showed no voltage. Checking on the oscilloscope revealed that the slider switch was only powered for a split second when either the on or off button was pressed, presumably to save power. The first three pads do this but the fourth is never powered. I assume this pad isn't actually used as if the switch isn't in the first three positions, then it logically must be on the fourth pad.

With everything working as expected I soldered on my connections and connected these to a header.

The program to actually interface with the device was very easy. I originally planned to use the tri state logic function to simulate the button being open. This didn't seem to work however so in the end I just used a logic high output. This is a bit wrong as the Pi outputs 3.3V logic which is higher than the potential of the controller but doesn't seem to cause problems. To simulate the button being pressed, a logic low output is generated from the Pi. For the slider, I just need to pull one of the three lines low or keep them all high to select device 4.

Naturally I made a video to go along with this hack...

http://youtu.be/qLB7Lr4YQ_4

As always the source for the Pi program can be downloaded at Lightwave Hack Source.

Siri, control my lights

2013-08-15T20:08:00+01:00

Once again, it's not moop but Charlie, so we're talking home automation instead of planes.

My last video on home automation turned out to be surprisingly popular! So, to celebrate I've done a quick follow up on the same idea. One thing people commented on was that I should have used SiriProxy. I had considered this when writing Jeeves (http://www.youtube.com/watch?v=gZkwvSX0_Os). I felt it wasn't quite as cool as having a device that listens all the time though. However, SiriProxy doesn't seem to require a huge amount of processor time so can run happily next to Jeeves even on a Raspberry Pi, so I thought I'd give it a go.

http://youtu.be/Z7gtugR2umI

Setting up was amazingly easy. I basically followed the instructions verbatim from the main SiriProxy page (https://github.com/plamoni/SiriProxy). There's a lot of complicated guides for old versions of SiriProxy but the latest version is quite simple to setup, so just follow the instructions from the main page.

The only thing I did differently to the instructions was that I had to copy my .siriproxy directory from my user directory to /root/.siriproxy. This is probably because when I generated the certificates, I wasn't root. You should be able to run SiriProxy as an unprivileged user but I didn't get that to work. It's only on the Pi so, I don't have any reservations about running SiriProxy as root anyway, so I just went with it.

Once the Pi was set up and running, all that was left was to set up my phone. This required e-mailing the generated certificate and changing the WiFi settings so that the DNS server pointed at the Pi.

With that working, next was the fun part of actually making a plugin for SiriProxy so it would do my bidding. There's already a LightwaveRF plugin but what's the fun of being like everyone else! Naturally I wrote my own. It's might be worse that the existing plugin, I didn't check before writing my own version.

The first hurdle to overcome was that the plugins need writing in Ruby. I'd never even seen Ruby code until I wrote the plugin so I probably didn't do things in the most efficient way but it was easy to get something working.

The main bulk of the plugin consists of these clauses...

listen_for /some regex/ do |variables,to,store,matches|
  say "Hey I recognised that"
  request_completed
end

Adding the lightwaveRF UDP protocol was easy from Ruby. First a socket is created and the host/port set up with...

s = UDPSocket.new
port = 9760
host = "192.168.0.10"

To turn on a device can then be done with only one line...

s.send("000,!R1D1F1|Siri|On", 0, host, port)

Each room contains a list of sockets that it has. When saying "There is a desklamp in the left socket", it first matches via a regular expression and extracts the two important bits, "desklamp" and "left socket". Next it verifies that "left socket" is a socket it knows about. If it is, then it inserts a new entry into the "items" hash map linking "desklamp" to the left socket.

When you say "Turn on desklamp", the word "desklamp" is looked up in the items hash map. If it finds a match then it sends the required command to the socket it was registered with. If it doesn't find anything in the map then it will check for a socket called "desklamp". Being a lazy programmer, the lights use this trick as they are implemented as just another socket. I could say "There is a banana in the lights" and I would be able to turn on my lights by saying "Switch on banana". That sort of bug, I don't mind letting slip through though as it's a remote possibility anyone would try.

I think that pretty much covers it. I hope someone finds it fun and has a go at implementing their own system.

If you want to look at my code, you can get it by clicking this siriproxy-lightwave.

Voice Controlled Lights

2013-08-10T16:07:00+01:00

It's not moop today but me again returning as a guest contributor. So, it's not planes or lathes today but wireless plugs and stuff.

If you read my last blog post (http://www.moop.org.uk/index.php/2013/05/27/homemade-wireless-plug/) you'll know that I tried building a cheap Bluetooth controlled plug socket that'd fit in a standard back box. When it came to actually installing though I got cold feet. There are safety and legal issue to fitting something like that into the wall so instead I opted for a commercially available version. I choose the LightwaveRF range of plug sockets and dimmer switches. These are just like what I was designing in that they just replace the standard fittings and are switchable remotely. With the LightwaveRF Wireless Controller this also includes controlling them across the network. They are pricey compared to my design but on the other hand, look a lot nicer and far less likely to catch fire.

The LightwaveRF network protocol is a fairly simple UDP scheme that's very easy to hook into (http://blog.networkedsolutions.co.uk/?p=149). The only strangeness is having to send a message with ID 533 first time to get the LightwaveRF box to prompt to register a new device. Coding this only took a few minutes and once that was working the only thing left was to think of something to do with it!

The most obvious thing to me was to live out Star Trek (http://www.youtube.com/watch?v=hShY6xZWVGE) by controlling things in my house by talking to them. "Computer, lights on" for example. I didn't want to leave a computer running all the time but I did have a Raspberry Pi lying around which I've been wanting to find a use for.

So, I started by looking for voice recognition technology to use. Doing a quick Google, bought up a lot of suggestions to use Google's voice API (they would say that! ;)). As much as I like Google, I don't really want everything I ever say getting sent to their servers, so that was out. Next best choice seemed to be CMU Sphinx. pocketsphinx is designed for embedded systems so seemed a good fit for the Pi.

On first impressions I was very unimpressed with CMU Sphinx. The accuracy of recognition seemed absolutely terrible. However it does have facilities to work with a subset of words for doing digit recognition for example. With a text file of commands I wanted it to recognise the lmtool (http://www.speech.cs.cmu.edu/tools/lmtool-new.html) creates all the files needed. Using these files the quality of recognition improved considerably. However there were still problems distinguishing "on" and "off". Also the word "Computer" was frequently misunderstood. So accepting this as a limitation of voice control, "Computer, lights on" became "Jeeves, lights up". Finally I adapted the voice model (http://cmusphinx.sourceforge.net/wiki/tutorialadapt) which improved the voice recognition even further.

Up until this point I'd been doing everything on my laptop but moving this to the Pi was fairly straight forward. I now needed some sort of microphone though. I tried Singstar mics at first. These worked straight off but didn't really do a very good job unless speaking directly into them. So next I tried another of my discarded game accessories, a PS3 Eye camera. This worked much better when picking up sound from across the room.

For sound output I used a pair of cheap PC speakers which I could connect to the 3.5mm audio jack on the Pi. I had spent some time trying to sort out a problem where the first second or so of audio when using HDMI output was silent. I tried updating the firmware and googled around for the answer. In the end I worked around this by appending a second of silence to the start of my audio output with sox. However when using the speakers the problem just went away anyway much to my relief.

As a finishing touch I made a quick LED display to indicate when the Pi was ready to accept the next command. While doing this, I decided to also wire up an IR LED so I could control the television too. Not having IR LEDs in my parts draw I just cracked open an old remote and took the LED out of there. I connect this to GPIO 7 as an arbitrary clock can be generated on that pin. I used this to provide the 38KHz modulation needed for my TV. I then toggled that pin between clock and a zero output in software to encode the commands to control the TV. This did not work at first. I could see on my laptop's webcam that the IR LED was flashing away but the TV did not respond. Cracking out the oscilloscope I found that the pulses when the output was a clock were all around 200us too long. I assume this is due to a delay in toggling the state. I decided to take the easy way out and just adjusted these timings. After these adjustments I was successfully able to control my TV using just an IR LED and a resister.

So enough talk, here it is in action...

http://www.youtube.com/watch?v=gZkwvSX0_Os

Nb. The source is downloadable here Lightwave Source. I warn you now though it's some pretty ugly code. A lot of this coding was done crouched on the floor working directly on the Pi. Getting back off the floor was my top priority, not following any coding standards. Still thought I should include it just in case anyone wanted some reference. The main guts, speech.c is just a modified version of the pocketsphinx continuous speech sample. irTrans turns the TV on and off and lightwave.c deals with the network side of things. speaker.c just keeps festival open so I don't have to pay the start up time when doing voice synthesis. Hope it's helpful to someone.

Unholy Chalupa MKIII

2013-07-08T20:58:00+01:00

Beware: unreasonably long post ahead. I probably should've posted this in chunks, but was hoping to fly the model first. That always seemed to be just around the corner, but thanks to British weather and seasonal man-flu that still hasn't happened.

The original Chalupa is a model aircraft I designed that was built over the Easter bank holiday last year. It was pretty simple but fun to fly, though not very pretty and the wing construction was rather flimsy. After it was built I continued tweaking the CAD drawing of the model. One of these tweaks was a lasercut version of the wing with an interlocking design that was a lot easier to build. Unfortunately, due to the hacks required to mount it to the old fuselage, it was still not brilliant structurally. When the second wing broke early this year I decided to do a full rebuild of the model, using the latest version of the drawing.

[gallery ids="241,314"]

The most major change to the model was the wing mounting system. The original and lasercut wings were built as a single panel held by a tab and a magnet under the fuselage. The intention of this system was to provide a quick release effect in the case of a crash or bad landing. Unfortunately, the wing tended to detach even in a good landing, and yank on the wing servo cables, in one case ripping off the housing from one servo and spilling tiny gears across the field. This also put a lot of stress on the center section of the wing in many cases. In the new design, the wing is built in two panels. A pair of carbon rods slide through holes in the fuselage. The rods continue through holes in the inner three sets of wing ribs. They should have enough flex in them to absorb some impact in the case of a bad landing.

As you can see from the comparison above, I also redesigned the fuselage to be much less boxy.

I cut the parts for the MKIII Unholy Chalupa at the start of May, using the laser cutter at Nottingham Hackspace. The model was finished around the 21st of June. Since then it's mostly been cluttering up my desk, waiting for a good day for a test flight.

The first step was to build up the fuselage sides. The side panels could have been built as a single piece if they were hand cut, but using the laser meant I could rely on the accuracy of the wing mounting holes. This allowed me to use the holes to perfectly align the doublers. This is important on this model, as the positioning of these holes will ensure that the wing sits exactly perpendicular to the fuselage. Once the doublers were on I attached the fuselage formers to the sides, unfortunately there were some errors in the CAD drawing, so I had to do a bit of trimming at this stage to get them to fit correctly. You can also see the 1/8th square balsa strip running along the top of the fuselage side. This is left unglued at the tail section for the time being so that the sides can be bent inward later.

[gallery ids="265,266"]

Once the glue on the formers had set, I carefully aligned the two fuselage halves and glued them together. A variety of clamps and blocks was used to ensure that everything was aligned and that the fuselage sides were vertical. The grain on the rear former runs vertically. This prevents it snapping if it is pushed from the top, but leaves it weak laterally so it could break if the fuselage is squeezed hard. To solve this problem, a cross grain doubler was added to the top portion of this former. A 1/8" square strip was slotted in temporarily to keep it aligned. This doubler also provides extra surface area for gluing, which will come in handy later.

[gallery ids="267,268,269"]

Once the fuselage sides and formers were in, the bottom sheeting was fitted. In the straight section of the fuselage this was straightforward. In the tail section this was slightly more complex, made more so by the fact that I had to trim part of the tail bottom section due to a CAD error. This prompted a rethink of how I link dimensions in my drawings, which I may write about later. Once trimmed the tail sheeting was pinned to the work surface and pressed firmly onto the rear former to ensure it remained straight. Once glue was applied, the sides were pulled in, held vertical using blocks and set squares. I also glued the 1/8th strips to the top of the tail section at this point, to lock in the bend.

At this point it was possible to put the model together to see how it would look and provide a motivation boost. The wings were held together by friction.

[gallery ids="271,273,275,276,277"]

The next phase of the build was to skin to the top part of the fuselage. The first part to be skinned was the hatch. This section detaches to provide access to the batteries and radio gear. Since it is separate it could easily be rebuilt if something went wrong. A 1/8" square spine was fitted into the notches at the top of the formers to support the 1/32" sheet was used for the skin. This was a slow process as it was initially glued vertically to the side of the hatch, then glued and pinned in sections once the glue set. This took several days, but very little actual work. Most of the time was spent waiting for the glue to dry.

The spine for the rest of the fuselage was glued in sections, taking advantage of the doubler on the rear former to provide extra surface area. At this point some 1/16" strip was added to provide a nice area for the sheeting to seat as well as additional glueing area.

[gallery ids="278,280,279,285"]

The sheeting for the cockpit and turtle deck was a bit more complex than that of the hatch. It was held in place and traced from the underside of the model, then cut and test fitted. A few attempts and some trimming were required to get this right. I left the rear end of the turtle deck untrimmed until I knew how the tail surfaces would fit.

[gallery ids="281,282,284"]

I originally intended to use the tail from the previous version of the model, but changed my mind after some consideration. On the original the elevator was a single piece with a slot in the vertical fin to allow it to move. This led to a lack of surface area on the fin and some yaw issues in flight. Because of this, I modified the plan to use a slot in the elevator with a just a small notch in the rudder for it to pass through. At this point power supply issues had taken the laser cutter out of action, so I had to make the extra parts by hand. I printed and traced the plans then cut them out. Since the notches on the cross grain parts of the surfaces were quite intricate I built the main sections first, then traced the notches on the cross grain parts from the real cut. After a few attempts I managed to get a nice tight fit.

It's important that the horizontal stabiliser and fin remain perpendicular, so blocks and clamps were used to hold them in place while the glue cured. A tiny sub fin was attached below the stabiliser, to give a place to hinge the lower part of the rudder. On the original model this was a big problem and lead to a very sloppy rudder response.

At this point the fuselage was mostly complete, and I moved onto the wings. You can see here that I've shortened the model a bit since the last picture of the fuselage. The original intention was to hide the motor away, but the problems accessing the mount made me change my mind. I think the model still looks good with the motor exposed.

[gallery ids="288,290,289"]

The wings are quite simple, but it's important that they are built straight. Because of this they were glued in several phases, with blocks and clamps ensuring that everything is straight and true. Unfortunately, for reasons I no longer recall, my original parts had tiny difference in the rib spacing in the outer panel. Despite taking great care to make sure the leading and trailing edges matched, I still managed to mess this up on one wing. This left the wing ribs slightly skewed, but in the end it doesn't cause a big problem once the wings were attached. Even so, I fixed this up on the plans so it won't be an issue should I build another.

You can also see that while the glue was setting the wings were placed back to back. This was to make any misalignment visible, so I could correct it before the glue set. I also measured the height of the trailing edge at each end of each panel to try and eliminate any twist. If I build another, I intend to make a jig that will slot over each rib of the wing, keeping them all at the same angle to the work surface.

[gallery ids="291,292"]

Whilst the glue was setting on the wings I installed the radio gear into the fuselage. On this model it's a tight fit, and the receiver will be difficult to get at once the model is covered. Fortunately this shouldn't be necessary except in rare cases, in which case the covering can be cut off to gain access.

The wingtips were installed with the wings attached and the model standing on its nose. I used some 1/8" strip packed around the tips to to keep them horizontal, as the slight bevel left by the laser cutter would create problems if they were just glued on directly.

Sub ribs were added to the wings for servo mounting. They slot onto the wing spars and the carbon rods that attach the wings to the fuselage. The servo is screwed into a slot the thicker of these sub ribs. The thinner two sub ribs provide a mounting surface for the sheeting around the servo horn, giving a place to attach the covering around the gap.

[gallery ids="295,296,297"]

To hold the wings in place, I settled on nylon bolts that fit into T-nuts in the inner rib. Since there were no holes for the bolts in the plans I had to manually drill these. I fitted the wing in place and pressed on the T-nut to leave in impression on the fuselage side, marking where the holes should be drilled. Although this holds the wing well, it is difficult to insert and remove them, so it's not the best method if the wing needs to be removed regularly. I need to put a bit more thought into a nicer mechanism at some point.

[gallery ids="300,299,316"]

Another benefit of the carbon rod wing attachment is that they provide a good hardpoint against which the landing gear can be be mounted. This was my first attempt at wing mounted landing gear and I'm fairly happy with how it turned out. It should transfer a lot of the landing loads to the rods instead of the wing.

[gallery ids="301,304,305"]

The leading edge of the wing was built up from a stack of 1/8" and 1/16" strip. I used parcel tape to protect the wing ribs while sanding these to match the desired profile.

After covering the tail and fuselage, I installed the tail. I took a lot of care to make sure it sat correctly and that the stabiliser was horizontal, before adding glue and clamping it in place.

[gallery ids="308,309,310,312,311,313"]

I waited until after the model was covered to fit the control linkages. The tail surfaces required relatively long pushrods, so I used adjustable EZ-link style fittings to make them easily adjustable, rather than risk messing up fixed length pushrods. This also keeps them removable as they are only bent at one end. For the aileron surfaces I used fixed length linkages since they are short and would be easy to replace if the length came out wrong.

Once a few more minor tasks were out of the way, the model was mostly finished and ready to go.

Unfortunately, thanks to the weather I haven't had chance to fly it yet, so it's been cluttering my desk. Since I was out of hooks to wall mount it in the usual way, I ended up bending a large wire hook that clips to the landing gear and could be screwed to the wall.

Homemade Wireless Plug

2013-05-27T15:02:00+01:00

Hello readers! First off, if you were expecting one of Moop's awesome posts then prepare for disappointment as today you have me, Charlie, posting instead as a special guest contributor.

The design

So, I wanted to automate my home. Nothing too exciting, just turn off an on lights and plug sockets using my phone.

So, the design main goals were...

Functional : It's got to work
Cheap : I aimed for a final price of under £10 per socket
Small : It had to fit within a standard wall socket/switch cavity

Reason for wanting it to fit within a standard wall cavity was mainly to make the installation both easy and invisible. The reason for wanting them to be cheap is because I'm weirdly cheap when it comes to building stuff. Maybe it's a hang up from doing similar projects as a student when I really had to to get the part spend down as low as possible. In any case I like the challenge of trying to design stuff on a shoe string.

Being a programmer I went straight to wanting a microcontroller of some kind. I had three ATtiny based DigiSpark boards from when I backed the project on Kickstarter (http://www.kickstarter.com/projects/digistump/digispark-the-tiny-arduino-enabled-usb-dev-board). This has almost blown my budget straight away but was rather convenient. It was around $8 from what I remember.

Next up, the communication. The most straight forward method seemed to be Bluetooth. It doesn't have much of a range but enough for our purposes. Originally I thought I could connect to the sockets directly from my iPhone however when I went to implement it, it became clear that Apple only support the new Bluetooth 4 Low Energy profile, which no cheap Bluetooth modules do at the moment. So instead, the idea became to run a web server on something like a Raspberry Pi that would have a Bluetooth module to talk to the sockets. This had the advantage of allowing things like trivially turning every socket into a timer socket with a nice web interface.

The Bluetooth module I went with was an HC-05. These are easy to find on eBay and with shipping cost just $5. A datasheet is here http://www.mcu-turkey.com/wp-content/uploads/2013/01/HC-Serial-Bluetooth-Products-201104.pdf.

We now need something to switch the mains current with. A relay seems the obvious solution for this. So back to eBay. I ended up with a relay that could be switched with 10mA current at 5V and could take 250V AC up to 10 amps. More than enough for almost any single appliance. I was mainly thinking about lighting so 2.5kW was more than enough. Cost including shipping: $1.50

Finally, we needed a transformer of some kind. I originally thought of building some sort of rectifier and voltage regulator to get the required power as the amperage I needed was so low. However, even at the small currents the amount of wasted energy would still be quite large, which would cause heat dispersion problems, so I went for a transformer instead. The ones I got were sold as LED drivers for things like Christmas lights. For our purposes it was very cheap and very small. This was around $3.

So all in, around $17.50 or £11.50, so a bit over the initial budget of £10 per socket. If we had an in system programmer we could use a plain ATtiny which would have only been around 60p ($1) instead of the $8 DigiSpark. Also ordering in bulk would have reduced the cost of the other components as the prices all included shipping.

The circuit was so simple that a schematic probably isn't needed. The transformer was wired into the mains power coming into the socket and the 5V side powered the microcontroller, Bluetooth module and relay module. The live wire of the mains went through the high voltage part of the relay to the socket. The control of the relay went to an IO pin on the DigiSpark. Three more IO pins were used by the Bluetooth module (RX, TX and KEY).

The Bluetooth module was 3.3V chip but the ATtiny is 5V. I didn't initially realise this until half way through building. I thought the ATtiny was 3.3V too. This was mainly due to measuring the voltage at Vin on the DigiSpark and seeing around 3.3V. This was the pin I powered the Bluetooth module from. However, this was actually caused by a voltage drop across a diode just there to protect the voltage regulator from being connected up in reverse (D'oh!). To prevent over driving the input pins of the Bluetooth module I also added diodes to the RX and KEY lines as a quick fix.

I connected the relay to default to on so if it was to break the light/socket would still be functional. The original idea was to wire up the transformer to the socket's switch as well, although this turned out to be difficult in practice. The reasoning behind this was that by turning the switch off it would not only stop the internals drawing power but if anything went wrong, there was a way to reset the microcontroller and if the system fell into disuse all the switch would still operate normally.

I also wired up the Bluetooth status LED as it was trivial to do and quite helpful during testing. In practice this wasn't a good idea as the flashing could be seen outside the socket.

The build

First thing was to turn the surface mount Bluetooth module into something a bit easier to work with. I'd never worked with surface mount parts before, so I decided to turn it in to a through hole part by attaching it to a bit of PCB. The spacing was quite small so couldn't use stripboard or the like. In another first, I thought I'd try printing my own circuit board. First, I cut a small piece of copper board. Then holding the Bluetooth module on with a bit of tape, I then drew draw up to the contacts that I wanted with an etch resist pen. Extending these I created pads for where I would eventually drill through to connect the wires. Then it was simply a matter of etching. This did take a long time (it was very cold that day and I was just doing it in a tray) but eventually patience paid off and I had my PCB. I then drilled the holes and finally soldered on the part which was straight forward.

At this point, I realised I'd completely destroyed my trousers! Pro tip: Don't wear your best trousers when working with acid.

With the most difficult part over, it was then just a case of soldering the parts together according to the design.

The software

So, on to the software. The ATtiny just needs to setup the Bluetooth module then wait to receive commands for switching the relay.

The Bluetooth module uses the RS232 interface. I originally thought I would have to do something complex to allow full duplex sending and receiving but in practice a very simple send, then wait for response worked perfectly well.

Format was 1 start bit, followed by 8 bits ASCII followed by a stop bit. Sending was as simple as...

// start bit
digitalWrite(TX, LOW);
delayMicroseconds(BAUD_RATE);
//character
digitalWrite(TX, (c&1)?HIGH:LOW);
delayMicroseconds(BAUD_RATE);
...
digitalWrite(TX, (c&128)?HIGH:LOW);
delayMicroseconds(BAUD_RATE);
//stop bit
digitalWrite(TX, HIGH);
delayMicroseconds(BAUD_RATE);

After sending a command string, it would then wait for a response using almost the complete reverse.

// wait for start of start bit
while (digitalRead(RX));
// delay to get the middle of first bit of character
delayMicroseconds(BAUD_RATE+BAUD_RATE/2);
// character
c|=(digitalRead(RX)==HIGH)?1:0;
delayMicroseconds(BAUD_RATE);
...
c|=(digitalRead(RX)==HIGH)?128:0;
delayMicroseconds(BAUD_RATE);
// could check for stop bit here as verification

The receiving would just loop until a newline character was read. This was assumed to be the end of the response.

Before we could start sending commands, we set up all the IO lines, then pulsed the KEY line low to get the Bluetooth module to start up in 9600 baud AT command mode. We could then start sending the AT commands to setup the module. In a real world case this would set up passcodes etc (so your neighbours couldn't control your lights). But for now we just gave it a name and made sure we got OK back.

SPARK: AT+NAME=PLUG\r\n
BLUETOOTH: OK\r\n

From this point the KEY line was returned to low to switch the module to communication mode. Once done it just waited to receive a character like we did before. A '0' would turn the relay off or a '1' would turn the relay on.

Next up was to code the web server. This needed to interface with a web page and send the 0 or 1 to the Bluetooth module.

Being trendy, I thought a Websocket's interface would be the way to go. Instead of doing the sensible thing and downloading a library, I decided to do everything myself. This turned out not to be a great idea. Firstly the websockets protocol seems needlessly complex. First, a key is sent which you have to transform and send back. This transformation isn't the easiest when you're trying to write everything yourself in C. First the key gets a magic string appended, then a SHA1 hash of this is generated and finally that hash is encoded in base64 ready to be returned. Even when the connection is established you then need to XOR everything you send. Not super complicated but lots of code to write. Weirdly although this worked perfectly with Chrome, both Safari and Firefox didn't accept my Websocket connection response. Moral of this lesson, don't pointless write functionality you could just download a library to do.

Although I planned eventually to run the server on a Raspberry Pi or similar, I started off programming on my laptop which meant I wrote the Bluetooth communication code using OSX's IOBluetooth interface. This allowed automatically pairing with the plug and the sending of the control signals. Not having done much OSX programming before, I spent a good hour or two pulling my hair out until I realised I didn't get callbacks unless I called CFRunLoopRun(). Once I realised this, everything went a lot smoother. Below is a cut down version of my pairing code (ie. no error checking etc).

inquiry=[IOBluetoothDeviceInquiry inquiryWithDelegate:self];
[inquiry setSearchCriteria:0 majorDeviceClass:kBluetoothDeviceClassMajorUnclassified minorDeviceClass:kBluetoothDeviceClassMinorComputerUnclassified];
if ([inquiry start]==kIOReturnSuccess)
{
  CFRunLoopRun();
  NSArray *devices = [inquiry foundDevices];
  for (IOBluetoothDevice *device in devices)
  {
    if (![device isPaired])
    {
      IOBluetoothDevicePair *pair=[IOBluetoothDevicePair pairWithDevice:device];
      [pair setDelegate:self];
      if ([pair start]==kIOReturnSuccess)
      {
        CFRunLoopRun();
      }
    }
    if ([device openConnection]==kIOReturnSuccess)
    {
      IOBluetoothRFCOMMChannel *rfChannel;
      if ([device openRFCOMMChannelSync:&rfChannel withChannelID:1 delegate:self]==kIOReturnSuccess)
      {
        // Now you can communicate on rfChannel
        // ie. [rfChannel writeSync:(void*)str length:strlen(str)];
      }
    }
  }
}

The object needs to implement callbacks but mostly these just consist of calling CFRunLoopStop(CFRunLoopGetCurrent()) when the complete callbacks is received. The only one I really had to implement was the PIN code exchange.

The wrap up

Next up was just to cram everything into the socket...

And try it out...

http://www.youtube.com/watch?v=GBEqYxaKBfM

So, I didn't actually meet my price goal or get it to fit snugly inside a standard socket. But it isn't too far off. I have a smaller (and cheaper!) transformer but haven't tried it yet. Also, there's lots of space to save by integrating parts like the ATtiny, Bluetooth module and relay driver into one PCB.

The relay might need some work too as it wasn't too impressive. After some time (a few minutes) it tends to return to it's default state (power on) even though it's input pin is still high. I mainly blame this on the power supply not being able to maintain a high enough voltage but that's just a hunch.

In practice I never put these in any sockets in the house. This was mainly due to safety (ie. fire) and legal issues (probably is illegal to replace sockets with own uncertified modifications). I am still interested in home automation but will probably play it safe and stick to the commercially available products.

Update

2013-05-19T13:04:00+01:00

I've had a sudden burst of motivation this morning, possibly due to a nice model flying day finally turning up (maybe the second this year!). I thought I'd use this to make a post since I've not updated in a while. I have a bunch of projects on the go, but they're all moving rather slowly.

For months now I've been building another R/C model, a Speed Twin ST2. The full size is a nifty looking and rather rare (2 prototypes made, one sold to someone in the US) twin prop aerobatic plane. It's somewhat of a departure for me as, with the exception of the HiFly, it's a lot larger than any of the models I've previously built. The plane was built from free plans in RCM&E Magazine, designed by Tim Hooper. I'm cheating a bit by using a CNC cut short kit they offer. Once I find some time I'll hopefully make a series of posts on the construction process.

Work on the Speed Twin has mostly stalled for the past few months. This was due to a holiday immediately followed by the arrival of my eShapeOko CNC machine, which stole a large chunk of my working space. In the short term, I'm planning on using the machine to experiment with mechanical PCB etching. The controller for the machine is currently built on a breadboard. If all goes to plan it'll be used to build itself a more permanent controller, and a nice housing for it too.

The controller is based on an Arduino running GRBL and four EasyDriver stepper controller boards. The DIY Arduino (made during a workshop at Nottingham Hackspace) doesn't include a USB to serial adapter, so I've hacked one together using a Minimus USB microcontroller board.

Unfortunately, I'm waiting on some PCB milling bits to be delivered, along with a few other parts, before I can use it in anger. Experiments with it acting as a pencil plotter are promising, and the accuracy seems more than sufficient for the job.

I'll hopefully write a few posts about some of the mods I've done to the machine shortly, and about building the final version of the controller once the parts arrive.

Last but not least, I've resumed work on the Unholy Chalupa, my own design model aircraft. The original Chalupa is a 22" span low wing trainer I designed in early 2012 and built over the Easter bank holiday weekend that year. It was designed in CAD but the parts were hand cut.

The original model flew well but the wing was overly delicate and became quite twisted after a few repairs. After shelving the model for a few months I redrew the wing with laser cutting in mind. I borrowed a lot of ideas from the style of Dave Thacker's micro scale models, which I'm rather fond of.

The new laser cut wing flew nicely initially, but was lightly built for this model. This wing broke during a crash caused by the motor working its way loose from the mount in flight. The wing was repaired, but due to one piece construction it was never really straight after that, making the plane less fun to fly.

The new design has a simplified two part wing that will plug into the sides of the fuselage. This will limit any damage taken to a single wing panel. Since this design change will require a new fuselage, I took the opportunity to redesign that too. The new design will be a lot less boxy.

I have the parts cut for the new design now, I'll post more about it once I get around to putting it together.

Glider Restoration Part 4 - Finishing touches

2013-03-03T00:31:00+00:00

The weather today was unexpectedly awesome so it would have been a crime to not try and take the glider out for a flight. I had to quickly make a few finishing touches before it was ready to go.

First off the connectors were soldered to the motor and ESC and the motor was mounted to the pylon. Ultimately, this needs further finishing work, but I'd like to make sure the motor is suited to the job before doing anything more permanent. The elastic band will keep the wires clear of the prop.

The clearance between the pod and the wing limits the prop to about 5 inches. I'm running a 5x5 prop with a 1650Kv (ie. 1650 RPM/volt) motor from a 3 cell Lithium Polymer battery. Hopefully this will provide enough thrust, if not I may have to try a 3000Kv motor.

I bought some large 5" rubber bands to hold the wing and stabiliser on, as the ones from the original kit had perished. To protect the trailing edge of the wing from being crushed by the bands I installed a pair of ply plates on the rear of the wings. I first cut away the covering from a section of the wing and then epoxied on some 1/32" ply plates. These were then recovered with a small rectangle of film to neaten them up.

[gallery ids="218,220,221"]

With this done the model is now in a state where it is ready to fly, and can be stored fully assembled. This made storing it a bit easier since it can hang on the wall above my desk.

Finally, I took it out to the field for a test flight. Fortunately a few other members of the Derby Model Aero Club were also out making use of the nice weather, so I was able to get a hand launch and a cameraman.

The model flew nicely as a glider. Unfortunately I only had a small battery charged which wasn't really capable of running the motor for an extended period without taking some damage. I also had to add a second heavier but incompatible battery for ballast to get the centre of gravity correct. Next time I have opportunity to fly it I'll use a larger battery so I can gain enough altitude for a proper test.

Glider Restoration Part 3 - Fuselage

2013-02-24T13:41:00+00:00

With the wings complete I moved on to restoring the fuselage of the glider. I'd originally intended to use the existing fuselage and just straighten it up. Unfortunately, when I came to look at it closer the plywood construction had warped more than I thought. I started trying to disassemble it with a view to re-glueing but it quickly fell apart, at this point it became even more obvious that the original ply was just too warped to be useful. I took the decision to build a new fuselage using as many of the existing parts as possible, but using balsa instead of ply for the majority of the structure. I decided it should be possible to build a structure with equivalent strength this way, with similar or less weight and less tendency to warp if stored for a long time.

[caption id="attachment_168" align="alignnone" width="460"] Twisty Fuselage[/caption]

The first step was to trace out the layout of the fuselage from the plans. This was tricky because the way the plans were folded (in the original packaging) they would not sit flat. They had to be stretched very tightly to avoid introducing curves into the lines. I took account of this when tracing and did a second pass using measurements from the plan and filling in the straight edges.

[caption id="attachment_169" align="alignnone" width="1024"] Tracing the fuselage parts[/caption]

Once I was happy with the outlines I traced them onto some balsa. The fuselage sides were cut at the same time by pinning and double sided taping two sheets together, in order to ensure that they matched. The edges were then sanded before detaching the sheets. Because my wings have a slightly longer chord I had to transfer some measurements from the new wings onto the fuselage sides. I then used the markings on the fuselage sides to determine the length of the top sheeting.

[caption id="attachment_171" align="alignnone" width="460"] Taking measurements from the new wings[/caption]

I was unable to reuse the original fuselage formers. In the course of removing the glue from them the wood began to crumble, also the thickness of the side sheeting had changed necessitating different dimensions for the formers. I built a servo tray shelf from thick balsa instead of ply to avoid the difficulties of cutting this part out of ply.

[caption id="attachment_172" align="alignnone" width="1024"] Original and new formers[/caption]

[caption id="attachment_173" align="alignnone" width="460"] New front former[/caption]

For the front section of the fuselage I cut some 1/32" ply formers to add back some strength. The were overlapped with the front former but did not go beyond.

[caption id="attachment_176" align="alignnone" width="1024"] Ply doublers[/caption]

I then fitted the new formers using blocks to make sure they were at right angles with the fuselage sides. The rear of the doublers was glued into place at this point, but the remainder was left unglued to make it easy to add curvature to this section later.

[caption id="attachment_178" align="alignnone" width="1024"] Fitting the formers and doublers[/caption]

Once the glue was cured the other side of the fuselage was fitted to the formers, again ensuring that everything was held perpendicular. Once this was set I put the fuselage upside down and began fitting the bottom sheeting, making sure that the fuselage sides were vertical at each point.

[caption id="attachment_180" align="alignnone" width="1024"] Adding the bottom sheeting[/caption]

With the majority of the fuselage bottom sheeting installed I had to fit pushrods before closing this area up. A sharpened aluminium tube worked well to drill out the angle pushrod exit holes in the fuselage. The pushrod outer tubing was roughed up and epoxied into place at the rear of the fuselage and held in place with rubber tubing at the front.

[gallery ids="182,183,184"]

The bottom sheeting in the nose section is thicker than in other areas and is sanded to provide a curved shape. I first traced out the shape I wanted and pinned and glued the fuselage sides into position using this template. I also glued the rest of the doublers down at this point to help maintain the curvature. Once the glue was cured I trimmed the bottom sheeting to shape.

[caption id="attachment_186" align="alignnone" width="1024"] Nose bottom sheeting[/caption]

To create a servo tray in the nose section of the fuselage I transferred the dimensions of the rear part of the tray (attached to the former) to a square stick of wood. I then used a servo and a piece of 3/16 sheet that would become the front of the tray to mark out the required dimensions. I used the stick to mark the inside of the fuselage sides with the tray position, then used pins to transfer these marks to the outside. Cutting a slot between the marks gave me a firm mounting for the front of the servo tray. This was glued in after the servos were screwed into it to maintain good alignment with the rear of the tray. The ends of this piece were then trimmed and sanded flush with the fuselage sides.

[gallery ids="190,191,192"]

To create the nose of the glider I first installed a ply former between the fronts of the fuselage sides. I the attached a stack of 3/16" balsa forming the rough shape of the glider's nose. These were hacked roughly to shape with a razor saw before being sanded to a smooth shape that I was happy with.

[gallery columns="4" ids="194,195,197,199"]

The wing saddle area felt a little flimsy so it was reinforced with two sections of 1/4" square section balsa on either side. These should help transfer loads across this section of the model and provide a sturdier support for the wing.

[caption id="attachment_193" align="alignnone" width="1024"] Reinforcing the wing saddle[/caption]

As with the nose, I built up a block of balsa at the very rear of the glider and sanded it to shape. This gives a neat finish to the tail as well as hopefully absorbing any impacts during transport and handling.

[caption id="attachment_196" align="alignnone" width="1024"] Tail block[/caption]

The fin was fitted last to avoid bashing it while working on other parts of the model. I was glued into a slot in the top sheeting, and held in place with blocks while the glue cured. I used the original fin as this part was still intact and straight.

[caption id="attachment_200" align="alignnone" width="1024"] Fin installation[/caption]

Covering the fuselage was a straightforward process as there are no open sections to cover over.

[caption id="attachment_201" align="alignnone" width="1024"] Covering[/caption]

With the majority of the fuselage built I fitted the original rudder and stabiliser to the model. The rudder was fitted with 3M Blenderm tape which makes an excellent hinge. The stabiliser and wings are intended to be held on with thick rubber bands, I need to go out and buy some stronger bands before flying the model. After centering the servos I trimmed the pushrods to length and fitted clevises, then tested the amount of force required to move the control surfaces. The rudder required quite a bit of force so I moved the control horn lower down on the rudder to better suit the angle of the pushrod.

Unfortunately I don't have access to a decent slope or any good means of launching the model as a pure glider. The HiFly comes with a motor pod that sits above the wing so it can be flown as a powered glider. I've assembled the pod, but I'm waiting on the arrival of a motor before I can fly it.

At this point I was able to fully assemble the model, which took up a lot more space than I remember. Various parts like the canopy and the stabiliser were reused from the original model. Once the motor arrives (hopefully next week) I'll be able to give it a test flight assuming the weather cooperates.

[caption id="attachment_203" align="alignnone" width="1024"] Assembled model, sans motor[/caption]

Glider Restoration Part 2 - Finishing the wings

2013-02-19T22:23:00+00:00

To finish off the wingtips, I cut off the spars at an angle and cut some tip skins based on the plans. These were glued and pinned into place then sanded to provide a smooth finish and to blend in with the leading and trailing edges.

With the tips finished I drilled holes into the inner three ribs of each wing. This was a process that would have been much easier earlier on, but would have resulted in the ribs being delicate and fiddly until the skin on this section was added. The first wing went fairly smoothly, but the spars on the second were slightly closer-spaced, resulting in my drill bit catching and breaking one of the ribs. This was easy enough to repair but frustrating.

I couldn't find any tubing exactly the right size to take the wing joiner, so I settled for taking some undersized tubing and cutting a slit in it to allow it to expand slightly. Cutting this with a rotary tool worked but was messy and went through several cutting discs.

I first test fitted the tubing to make sure it the wing joiner would fit. Then I wrapped it in tape to make it easier to remove should I need to, before epoxying it into the slot in the wing. Once both wings were done I installed the joiner as a test only to find there was a slight misalignment that I'd missed. I was glad of the tape at this point as it made it much easier to remove the tubing before re-drilling and refitting the tubing!

Once the joiner tube was in place and both wings lined up I cut some wood for the sheeting on the inner section of the wing. This was quite straightforward as the shapes were simple and the dimensions could be directly taken from the wing. Once these were cured I glued on the 1/32" ply faceplates to the root rib, using the wing jointer to align them.

With the wings complete it was time to cover them. As usual I used an iron on film, in this case LightTex. I prefer to tack the film to the trailing and leading edges first, to avoid it moving about. After this, I worked from one end of the wing to the other to avoid the shrinking film creating too much tension and pulling a warp into the wing.

I kept the original decals from the previous model when I removed the covering, and my initial plan was to reuse all of these on the new model. Unfortunately the covering that the second of the larger decals was attached to began to disintegrate when I attempted to remove it so I was left with only one good decal.

To deal with this I decided to trace out the lines of the decal and create my own from some left over red and black covering film that I had. This worked surprisingly well and I decided to remove the other of the larger decals and use the same technique on the first wing also.

[gallery ids="155,156,158"]

After tracing, I transferred the lines onto some paper and cut them out neatly. This provided a template that could be taped to some covering film and cut out with a sharp craft knife. I did this for the swirl and the individual letters, then arranged them on the wing. To iron them down I covered the sealing iron with a sock. This was to prevent the small pieces of film from shrivelling and attaching their adhesive side to the iron.

I lost some detail in the decals by using this method, but it still looks good. The original decals looked quite messy due to air bubbles under the transparent parts and dust getting stuck to the adhesive around the edges.

Space saving wall art

2013-02-02T22:44:00+00:00

I seem to have too many model planes nowadays, and storage was fast becoming a problem. During a bout of boredom, I dug up some screws and hooks and attached them to the wall above my desk. Now they look cool, and I have loads of extra space!

Model glider restoration

2013-02-02T22:35:00+00:00

I've had a Precedent Hi-Fly model glider lying around waiting to be repaired for years now. I originally built it with my dad. Well, he did most of the building; I suspect my main contribution was nagging him to get it finished. Unfortunately, we didn't really know what we were doing, and it took some damage after very little flight time. We attempted to use a plastic AA battery box which broke as we launched the glider and left us with no control.

The nose of the model was damaged when it landed, and it was put in storage for many years, during which the wings got warped. A year or so ago I decided to restore it, I finally made a start on it last week.

I decided to completely rebuild the wings, as the warp in the originals was enough that it would be very difficult to remove without weakening them. First off I dug out the plans and found an image showing the typical wing section. I traced this in Draftsight to provide the shape for the various wing ribs. The tip ribs where the wing tapers had to be generated by measuring the plan, then scaling and fixing up the slots.

Unfortunately in my hurry to get the ribs cut I drew them in a hurry and made a few mistakes. I missed the asymmetrical spar slots on the inner ribs and added a slot where the shear webs were drawn on the plan, leaving me with two part ribs. I didn't catch this before laser cutting the parts, but I was able to work around the problems and avoid wasting the cut parts. I guess the moral of the story is "Don't design in a hurry". The drawing shown above includes the corrections I made later. The thin ply end plates had to be cut by hand around a template as I couldn't find laser safe 1/32" ply.

I traced the plan onto some greaseproof paper since the original plan was too creased to build on top of.

The actual wings went together fairly quickly once I got started. The spars were pinned to the board and the 1/8th inch ply and balsa inner ribs were laid on top. They were packed to sit level because they're cut 1/16th of an inch undersize so they can be sheeted later. I then added then top spar and supported it at the other end. A small template was used to set the angle of the root rib, to give the wing the correct amount of dihedral.

Between each pair of ribs is a shear web that locks the spars together, and prevents the wing from twisting or flexing. These came in handy to hold the front end of the ribs in place, meanwhile the rear ends of the ribs were pinned. A set of building block blanks from Homebase came in handy to make sure everything was square. I tend to clamp them to parts until the glue sets to keep them oriented correctly. Fortunately I had enough clamps that by the time I ran out the glue on the first pieces was dry, so the clamps could be reused and the build went fairly quickly.

Once the rear ribs were in place, I marked the positions of their ends on a piece of trailing edge stock. I cut out notches then glued and pinned it to the board. This kept the rear ribs safe while I moved on to the front section of the wing.

Due to the mistakes I made when drawing the parts, the inner ribs were 1/16th of an inch longer than the outer ribs. To work around this I glued a strip of 1/16th balsa to the rear of the leading edge stock I was using, stopping where it met the inner ribs. I glued this to the inner ribs and pinned and clamped it in place, then installed the front rib half at the tip of the wing. This had to be clamped in in place with a pair of building blocks to keep it at the right angle. I then pinned the leading edge to the board to make sure it was straight according to my drawn layout before fitting the rest of the front rib halves.

Once the ribs were installed, I had to do some sanding to fix my design mistakes. I then fitted a piece of sheeting between the spar and the leading edge on the top side of the wing. This is designed to be glued into the top of the leading edge and then sanded to blend it in later.

Once sanded, the sheeting gives a very neat and uniform look, which hides many of the problems caused by the drawing issues. The curved tips play a perspective trick in the photo above, making the sheeting look flatter than it is.

The next task on the wings is to build up the tips and install the inner sheeting. I also need to drill a hole in the inner ribs to hold a tube into which the wire wing joiner will slide. Later, I will need to fix up the fuselage, but this should be a simpler job.

Mittens and Snowdrop action figures

2012-12-28T18:43:00+00:00

I got close to biting off more than I could chew recently in the process of making a Secret Santa gift. With Mata as my 'victim' I decided to make some little action figures of the Mittens and Snowdrop characters from one of his animations.

The initial plan was to just build and paint the figures, but partway through I decided to cast them in resin. This has the advantage of being stronger than the master model (depending on materials) and as a bonus let me make a set for myself.

First up, here's the finished product:

To start off with I decided to have some fun, and ended up building a mini lathe to make the basic body shape. This allowed me to use cheap 3/4 inch balsa dowel as stock material instead of wasting (slightly more) expensive putty, it also made getting the body shape smooth and uniform a lot easier.

The lathe is very light duty but works well to shape a piece of balsa with sandpaper or a craft knife. There's a separate blog post on how I made the lathe.

Once I had the body shape I started adding details. Mittens' mouth was just cut out with a razor saw and then the throat drilled out. After that, a lip and uvula were sculpted with Milliput epoxy putty. Eyes and feet were added in a similar fashion over several days to allow the putty to cure and prevent accidental damage to bits of detail that were still setting.

More complex features such as Mittens' hands and the ears were made by rolling out sheets of putty and cutting it to shape with a sharp sculpting tool. In the case of the ears they were rolled onto a curved bit of clay and cut to shape then allowed to cure and trimmed down to size before being attached with fillets of putty.

Once the masters were finished I brushed them with polyurethane varnish to ensure they'd release cleanly from the mould. I should have used some filler at this point to get rid of the woodgrain finish, but since I didn't think about it at the time I had to clean this up later.

I ordered some RTV (Room Temperature Vulcanising) silicone rubber online in order to make the mould. The correct way to make a two part mould is to build a box and fill the bottom half with clay, then press the masters into the clay and pour silicone over. Unfortunately the clay I had dried up, so I ended up using salt dough and surprisingly it worked well though it was very soft.

I build the mould box out of cardboard protected with parcel tape. The base is some 0.5mm sheet styrene I had lying around. The card was just formed into a box and taped closed I packed the bottom half with salt dough. I added more dough around the box to seal the edges. The master models were then pressed into the dough making sure there was a tight enough seal all around. I then mixed up the silicone thoroughly and poured it from as high as possible. It's best to pour into the corner of the mould and allow it to flow over the models of its own accord to prevent air bubbles and voids in the mould.

To make it easy to line up the two mould halves it's worth pressing the handle of a paint brush or similar into the clay to make some small alignment nubs in the first mould half. These will translate to matching holes in the second half. I made once larger than the others to make it obvious which corners should match up.

After leaving this overnight I removed the box and washed off the salt dough from the models. A downside of the salt dough is that it gets very sticky but it wasn't difficult to remove. Although it's advised against I cracked part of one of the models out of the mould to check that it released properly.

Before pouring the second half of the mould I painted a thin layer of Vaseline over the rubber (but not the models) to act as a mould release and avoid the two halves bonding together. I realised at this point that I hadn't added any vents or pour channels into the mould so I had to hack them in with some clay. These would have been much easier to add when making the first mould half as they could be set into the clay. The Vaseline didn't help either as everything was very slippy at this point.

The second mould half was then poured in a similar fashion to the first. A day later once it had cured I cracked open the box and managed to separate the two mould halves with relatively little hack and slash with the craft knife.

Once the mould was complete I mixed up some resin and did a test pour. The results were quite promising but highlighted a few flaws in the mould. The pour channels had to be opened up a bit with the craft knife to let more resin in. Additionally since the feet were above the point where the pour channel hits the body they trapped pockets of air. I solved this by skewering the silicone with a cocktail stick through to the tips of the feet and inserting some 'biro inner' style nylon tube to prevent the channels from closing up. The resin doesn't stick to the nylon so they can be easily removed with some pliers, leaving a little stick of cast resin which easily breaks off (useful for parts that can't be aligned with the mould line).

I used some more sheet styrene and elastic bands to hold the mould shut. It doesn't need too much pressure as the resin is quite thick and you can warp the mould.

It's worth noting that the resin and silicone I used required mixing in roughly 10:1 ratio with a catalyst, which required some very accurate scales. It's possible to get stuff that can be mixed 1:1 by volume which is a lot less hassle if you can get it conveniently.

Once the resin was cured and cracked out of the mould I trimmed off the flashing where the mould halves joined and primed them with grey spray on primer. At this point I noticed the woodgrain had transferred through from some parts of the bodies and other parts were not so smooth. To fix this I used some filler and a few rounds of sanding/filing and re-priming until I was happy with the finish.

Finally I painted the models with a mix of Citadel and Vallejo paints I had to hand and varnished them with some EzeCote polyurethane.

DIY Mini Lathe

2012-12-23T14:27:00+00:00

I needed some smooth round parts recently for some models I was building and chose to take an unconventional approach by building a mini lathe on which to turn them.

The parts were designed in Draftsight and cut from 3mm ply on Nottingham Hackspace's laser cutter. The lathe is built from two finger jointed boxes on a base plate. One of the two boxes has plates screwed inside and outside of the faces to hold a pair of bearings that support a free spinning motor shaft. The second box has an old GWS brushless motor mounted inside. The friction fit seems sturdy enough but two rails of beech engine bearer stock are screwed to the sides for extra rigidity and the base is clamped to a worktop to reduce vibration.

A suitable electronic speed controller and lithium polymer battery provide power to the motor. Control signals for the ESC are provided by a cheap servo tester.

[gallery ids="19,30,33"]

The work piece is drilled out slightly smaller than the two shafts and threaded on. The friction fit acts as a clutch helping to prevent damage to the motor or drawing excess current and puffing the battery if it stalls.

For tooling I used various forms of sandpaper and a craft knife. Anything that will cut or erode the workpiece without stalling the motor should work okay. I've found it takes a delicate touch but it is easy to shape the workpiece with some practice.

[gallery ids="35,43,11"]

There are a few downsides to the simple construction: the rails need to be unscrewed and the boxes removed to insert or remove the work piece, and the lathe is only suitable for turning very soft wood such as balsa dowel. Regardless of this the very low cost and simple task required of it it did an excellent job, though I won't take responsibility for any fingers lost attempting to replicate it.

About

2012-12-22T19:01:00+00:00

Hi, I'm moop and I have a habit of making things.

Hopefully this will turn into a place to write about them, instead of resigning them to the back of a cupboard.