Category: Electronics

High power LEDs

I've got a few 3W RGB LEDs that I've been meaning to play with, so over the Christmas break, I decided to hook 'em up to the bench PSU and have a play.

3W RGB LED

As I have but one variable bench PSU with current limiting, I could only easily light one LED at a time. I didn't have big enough resistors to build individual LED current regulation circuits - I just set the current limit on my PSU to 0.35A and cranked the voltage up until it maxed out, hooked up to one LED in turn.

They are certainly dazzlingly bright:

RedGreenBlue

Since the green and blue LEDs both have the same forward voltage, I figured I might be able to drive them together by using a pair of resistors as a current splitter, and setting the PSU for 700mA, thus ensuring that 350mA went to each LED.

However, my 0.25W resistors started to smoke when I got to about 400mA, so I shut it off - if one of the resistors burnt out then the entire 400mA would go into the surviving LED, overloading it (until its resistor also burnt out), and possibly making the thing explode. I ended up with a nice pair of burnt-out resistors:

100ohm 0.25W resistors, all burnt out after carrying 200mW each

Which is a shame, because I'd love to see how bright the thing is at maximum, with all three LEDs going!

My lab partner was most impressed, and asked me lots of questions about current and voltage; I had to resist her demands to keep making things, so I could go inside and write this blog post:

Jean enjoys watching me do electronics

Bench PSU made from an old PC power supply

My first PC compatible was an actual PC. As in, the original IBM PC - not even an XT. It died a death, but I salvaged the power supply from it, with the nice red switch, to be a bench PSU for my electronics experiments:

An original IBM PC power supply

It supplies -12v, -5v, 0v, +5v, and +12v. Which served me well for some years, but these days, everything's 3.3v or 1.8v. And my termination setups - first wiring directly into the row of screw terminals on a breadboard, then later a bit of wood with metal strips nailed to it so I could attach croc-clips easily - all left something to be desired.

So I got busy and built this:

The bench power unit (switched off)

Complete with a power LED so I can see at a glance if it's live:

The bench power unit (switched on)

Inside it's quite simple. Most of the terminals are fed directly from the PSU via the black cable, but I added an extra wire for an earth connection to the chassis (which I checked was really earthed) for ESD wrist straps. I mounted 3.3v and 1.8v linear regulators on a bit of stripboard along with the LED and its series resistor, and hooked it into the 0v and +5v lines.

Inside the bench power unit

Job done. Now the last bit of major infrastructure I need set up is to get Ethernet into the lab so the PC I have in there for driving the dev boards can access the Internet and my version control system...

The workshop’s getting there

My good friend and colleague Andy came over to stay for a while, which meant I had 'entertaining a guest' as an excuse to do some of the fun stuff I've wanted to do for ages.

So we finished making the welding bench! I'd made the top and gotten part way through cutting the legs to length, so we finished cutting them and welded them in place, then welded extra flat strips around the bottom to make it reasonably rigid. It's all just tack welds, and it'll almost certainly need some diagonal struts added, but it stands upright and is surprisingly sturdy; I'm going to experiment with it a bit to see just how many more struts it needs. I'd also like to drill holes so I can mount my vice on it, too.

Then we cleared a space and moved my electronics workbench down into the workshop! This is great news, as it clears up space in the office (albeit revealing the piles of junk that were lurking beneath the bench), means all my tools are in one place (which is most convenient, as things were always in the wrong places), and creates more storage space in the little garage, meaning less stuff on the floor.

I've since reincarnated my power distribution rail, which I had when we lived in Ealing, but haven't used since; the idea being that it'd be good to do my electronics experiments on the end of a dedicated RCD so I don't trip the one in the house. It also splits the output into four circuits, each with a six amp circuit breaker (the smallest I could obtain easily).

I still need to get rid of a lot of waste cardboard that's sitting around, and we're still looking after Seth's motorbike, and there's still junk to be sorted - many things need to be elsewhere; the little garage isn't a place to store things we only use a few times a year, as we have the Big Yellow for that!

Although the lighting's not really good enough when I'm explaining the power rail, here's a quick video tour:

For my next trick, I'll stop procrastinating by building infrastructure, and get on with actually making myself a digital watch with an embedded ARM processor and colour dot-matrix LCD. Watch this space.

Circuits in Epoxy

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:

the circuit side profile

Then I mixed up some resin:

mixing the 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:

resin in the box

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:

Underside of the castingTop side of the castingDetail of the top surface

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

Look, it works underwater!

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:

Propped up so you can see all the LEDs

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

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...

WordPress Themes

Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales
Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales