Circuits in Epoxy (by alaric)

Continuing from my previous experiments in epoxy casting, this time I decided to cast a circuit in epoxy, as that's my eventual goal.

So I made a test circuit with four LEDs and their series resistors on a large piece of stripboard, with unnecessarily long leads on everything and a few different orientations of components, in order to check whether shrinkage is an issue at the kinds of scales I plan to work at:

Then I mixed up some resin:

And poured it into a business card box and placed the circuit in. I chose the business card box since it looked like the same sort of plastic the proper moulds at resin-supplies were made of, and that's supposed to not stick to the epoxy:

Luckily, it seemed that the epoxy does indeed not stick to this stuff, as it came out easily, leaving a perfectly clear surface, with no damage to the electronics:

It's really weird to have one of my sloppily-made circuits that's completely waterproof and ruggedised:

We had to prop it up with one end out of the water so you can actually see that all the LEDs are lit, though:

I think I'll still need to experiment with silicone moulds, though - as I'm unlikely to find boxes of the right plastic in the precise sizes I want.

Insomnia (by alaric)

yawn

5:30am and I haven't slept a wink yet! I really need to sort out my lifestyle so I get (a) exercise and (b) time to think every day. Time to think is important for me; if I don't get enough, then when I go to bed, I lie there and think. Lots.

Tonights thoughts have included:

1. Some ideas about how whole-program transformations (eg, the macroexpander/partial evaluator and the OO system) in CHROME might be handled. The OO system needs to be a whole-program transformation rather than just some macros using the normal macroexpander since things like inheritance graphs and method lists for generic functions need to be accumulated together; most Lisps handle that with macros that destructively update data structures, but I'm trying to design a system without rampant mutation, so need a whole-program code walk to do this. Clearly, since we want to be able to write macros that produce generic functions, methods, and the like, we need to do this AFTER normal macro expansion, but before the compiler gets its hands on it.
2. Some ideas about separating the generic function/method system - the dispatch part of Lispy OO - from the classes-inheriting thing. Subtype relationships that are used to dispatch GFs should be doable with plain predicates - pair? my-record-type? etc. Or more complex predicate expressions on groups of arguments, so we can support multivariate typeclasses in the Haskell sense, as a rich interface/implementation system as well as a traditional records-with-single-inheritance class system. To do this properly we also need declarations that one predicate implies another - (number? x) -> (integer? x) - so that a method on numbers will be used for integers, yet a more specific integer method can override it. I'm not sure how decidable the "most specific method wins" thing can be with complex multivariate type predicates, though. Must experiment and ask knowledgeable formal logic folks.
3. Thoughts about future computer architectures. The drive is for more speed, but these days, most CPUs are idle waiting for memory to feed them code and data, or (much more often) for the disk, network, or user to feed them. The only places where the CPU maxes out tend to be highly parallelisable tasks - server stuff handling lots of requests at once, games and other audiovisual things, and scientific number crunching. This suggests to me that a future direction of growth would be one or more high-bang-per-buck MISC processors embedded directly into SRAM chips (sort of like a CPU with an onboard cache... but the other way around, since the CPU would be much smaller than the SRAM array) which are bonded to the same chip carrier module as a set of DRAMs. One or more of CPU-and-SRAM and some DRAM chips are then all designed together as a tightly-coupled integrated unit for maximum speed due to short traces and the lack of standardised modular interfaces between them (like DIMMs and CPU socket standards) meaning that the interface can evolve rapidly. The whole CPU+SRAM+DRAM unit is then pluggable into a standardised socket, which motherboards will have several of. The result? Lots of cores of low power consumption reasonably fast CPU with high speed access to high speed memory. And for those demanding games/media/scientific tasks? The higher-end modules will have FPGAs on as well...
4. Forget nasty complex unpredictable memory caches: have a nonuniform physical address space (with regions of memory of varying speed) and let the OS use the virtual memory system to allocate pages to regions based upon application hints and/or access statistics. Not having cache tag and management facilities makes for more chip area to put actual memory in.
5. We've been wondering about getting goats lately. Goats are useful creatures; they produce milk (which can be turned into cheese) and they produce decent wool (just not in the quantities sheep produce it). Their milk and cheese don't make Sarah ill the way cow-derived versions do. Plus, we need something to come and graze our paddock. We've been doing a little bit of research and apparently two goats would be about right for the space we have. We'd need to put an inner layer of fence around the paddock to keep them in while still allowing the public footpath, and we'd need a little shed for them to shelter in. But thinking about setting things up in the paddock, I'm now wondering if it would be a good idea to build a duck run in there too, down at the bottom by the stream, all securely fenced against foxes and mink and with a duck-house up on stilts in case of flooding, but with a little pond dug out for them (connected to the stream by a channel with a grille over it to prevent escapage). It would be a convenient place to have the ducks, and it would make a good home for them, I think.

It's now 6am. Do I try and go to sleep, or try and last the day out? Hmmm...

Is it normal to want to assign every object you own a serial number, then keep a database? (by alaric)

I've been doing some systems work in a rack recently that uses redundant systems. Two optical fibres come into to two switches which are connected to two routers and two load balances, and every server has two or more network interfaces (since there's internal and external VLANs).

So there's rather a lot of cables in there! Since the spare length is all neatly bound into a bundle, finding the other end of the cable you're looking at is a bit of a pain.

So I'd like to number each cable, label each end of the cable with its number, and add cable numbers ot the "what's in what port of which switch" spreadsheet.

Most cable marking systems, however, have to be applied before the plugs are attached to the cable - since they involve a sleeve that goes over the cable. This isn't good, since I want to label existing cables.

Hunting about online, I found these folks who do a nice line of markers - including the PC range of snap-on markers for existing cables. Lovely!

They've sent me a pack of samples, so I can experiment to see what fits best on my cables:

...and it looks like PC40 is the best size for CAT5 UTP.

Big Voltmeter (by alaric)

My mate Seth brought me back a lovely big AC voltmeter from India, where the power distribution systems tend to reflect an earlier, more exciting, time where things arced and crackled, and everything was made of Bakelite.

Anyway, it's meant to mount on a panel, and the rear of it just has two exposed screw terminals. So I had to do a bit of work to make it usable.

Firstly, I obtained some crimp terminals - a nice set with eighteen different kinds, including rings, spades (male and female), forks, and butt splices in three different sizes.

Anyway, I really wanted it for the ring terminals, which would securely attach to the screws on the back of the voltmeter. So upon returning to home, I went to Maplin and obtained a large enough box, then spent a pleasant hour or so in the workshop with my father in law drilling holes in the box so that I could mount the voltemeter on it. We also scraped away some paint from the inside of the mounting holes, exposing the bare metal, so that I could attach another ring crimp terminal to the mounting bolt as an earth connection. Better safe than sorry!

The end result is a nice box with the voltmeter mounted on it, with no exposed live metalwork, and a standard mains plug on the other end so it can monitor my mains voltage. This is a pretty useful tool, since we do get power cuts and brownouts and so on quite often out here, and the lights often change brightness at random...

As I write, it's reading a bit over 230v, while earlier, it was reading more like 225v. At some point I'll ask Sarah to turn the shower on (our biggest load) and we'll see how much the voltage drops - because I know the lights usually dim when the shower comes on 🙂

24-core CPU (by alaric)

Hurrah:

SEAforthâ„¢-24A Embedded Array Processor

I'd been hoping something would come of this since I first came across the original design.

I still think much more RAM is needed, though. As it stands it'd be great for processing most kinds of streamed data, where you don't need to store much context, but for more general purpose applications, much more RAM is required, and with a high-bandwidth link to the processors that need it, too...