Alaric’s projects for this year (by alaric)

This year's going to be pretty busy with settling into the new home, but I have a few projects.

1. Finish the ring casting I nearly finished before the move. That's a priority.
2. Resurrect my aluminium foundry. In particular, it's our bronze wedding anniversary, so Sarah's going to design a pattern for a sundial, which I will cast in Aluminium bronze, a nice alloy that I can make myself from my scrap aluminium and bits of old plumbing...
3. Continue with minor stuff on Ugarit, but as a milestone, build the distributed storage backend, which will rock.
4. Work on my wearable computer project. No specific milestone for this, as it's currently a long drawn out research/prototyping phase as I sort out many details.

Wish me luck... I usually suffer from "all my weekends getting eaten up", but as my New Year's Resolution has been to spend at least one day every two weeks doing something fun with my children, I'm going to be booking weekend days in my calendar in advance through the year for that and my own projects. Before they get filled up!

Ring casting (by alaric)

A friend has asked me to cast her some silver wedding rings. So I am adapting my aluminium casting experience to silver...

The thing to use for silver moulds is cuttlefish bone, which is soft enough to easily carve into shapes, but can withstand the heat of molten silver. For a single pour, at any rate.

In order to get a repeatably round shape of the correct diameters for the two rings, and so I can quickly carve new moulds if my pouring fails so I can try again, I decided to make boring tools that carve ring shapes of the correct diameters.

As you can see, they're made from nails, hard soldered together, and ground to a cutting tooth at the end. The central spike goes down a guide hole I drill in the cuttlefish in advance.

The tool needs to come down exactly perpendicular to the flat surface of the cuttlefish (made by sawing one side off and then sanding it flat), so I made a special jig to hold them:

Then it's just a matter of fitting the tool in a chuck and bringing it down. I first tried rotating the tool by hand, but the result was a bit rubbish, so I bit the bullet and just turned the Dremel motor on, which produce a quite perfect circle.

I made a couple of moulds, each with a matched flat cuttlefish to go on the other side. I had to carve channels for the silver to flow in by hand, using a screwdriver for rough gouging and a craft knife for the finer parts.

The silver was heated by blowtorch, in a refactory cup called a scorifier:

But first I had to prepare the silver I was given - in the form of a coin, which I felt a bit bad about sawing in half:

I melted half of the silver and poured it into the first (roughest!) mould:

When I cracked it open, it seemed I'd not used enough silver, but everything had otherwise gone well:

So I pulled the incomplete casting out, crushed it up, and added the other half of the silver, and gave the second mould a go. Here's a picture of it with the channels cut, before I clamped it:

I put it all together and got ready for some melting:

But this time, as soon as I started pouring, the silver suddenly froze on me, so hardly anything went into the mould:

It seems that the larger mass of silver wasn't heated up quite as far as the first pour had. I need to rearrange my firebricks to make a better forge to heat the silver in, so heat loss is slower, I suspect...

Hall effect sensors (by alaric)

At the Bristol Hackspace this evening, I powered up a Hall sensor.

The Allegro A1321 takes a 5v supply and outputs 2.5v - plus or minus 5mV per gauss of magnetic field in the sensor.

It turned out that small magnets don't produce many gauss, so I added a 741 op-amp with a gain of about 100 to get more useful output voltage deflection!

Here's the experimental setup:

WIth no nearby magnets, we read about 3v:

But with a very nearby magnet, we get a large deflection, which drops as we get the magnet many cm away, but is still significant:

Clearly we still get significant readings a good distance away, and the nonlinearity isn't too bad; it doesn't max out with the magnet very close but still varies many cm away.

For my next trick I'll make a few of this circuit on some veroboard and hook the outputs up to an AVR with several ADCs that I have lying around, and try comparing the results to measure position (and maybe orientation?) of a magnetic probe...

Motivation (by alaric)

Pass The Conch (by alaric)

In The Lord of the Flies, the children (marooned on an island and working out how to organise themselves to survive) develop a technique for managing debate: they use a conch shell as a token to represent who currently holds the floor. Without the conch, you can't talk; you have to wait your turn.

Cut to the Real World of Commerce and Industry: in various places I've worked, there's been a number of shared resources which can only be used by one person or agent at a time. Mainly, these have been testing servers - if you are doing performance analyses, or looking for timing-related bugs, you can't have anyone else running jobs on the same server as you, or they'll compete for resources and interfere with your results. Or perhaps there's only one "data area" of some kind, and two attempts to use it at once will lead to catastrophe.

This is usually handed by asking around the office or in IRC: "Is anyone using X?", hoping that anybody who is is still around (as opposed to too busy doing something to notice the request, or leaving a job going while out to lunch). Because of the unreliability of this system, and the inability to integrate it with automatic systems that need to claim resources (such as automatic test systems), I have often wished for a software tool to manage it. Which would, naturally, be called "conch".

Here's my feature wishlist:

• Network-based. A central conch server tracks a set of conches, accessed via a Web interface or a direct protocol. The direct protocol should have a command-line client for scripting, and be trivial to write native client libraries for in programming languages.

• Authenticated. No need for super security, but we want to keep out casual mischief-makers, so require authentication to use the server; to enable easy integration with other workflow apps, support htaccess files, "trust the upstream proxy" (eg, accept HTTP auth usernames and ignore any passwords sent), or running an arbitrary shell command to validate a username/password pair. It might be used across the public Internet, so allow for SSL wrapping the connection. The command line client should, by default, use the username and password from ~/.conch or prompt for them (and save them in ~/.conch) if not specified.

• The ability to create or delete resources, to claim a currently-free resource, to release a resource you hold, or to "force" the release of a resource that somebody else holds (if they forget and go home, etc).

• The ability to list the status of a resource, to list the resources held by a specific user, to list the resources held by yourself, to list all users with resources held, and to list all resources.

• Fine-grained access control (per-user rights limitation) might be handy, but probably not useful for the first draft.

• An IRC bot might be cool - at least for logging resource claims/releases and commands to list current state; maybe for resource claims/releases as well, if users are either trusted by nick or authenticate via a private message.

If this doesn't already exist, it should be easy to build (something could be knocked up with awful and sql-de-lite in a day or two, I bet!)...