The SenseLamp is an ultra-low cost (less than 30GBP/45US$), WiFi enabled sensor platform that is easy to build, easy to deploy and fully open source. A SenseLamp is a lamp shade that can be remotely controlled and gathers temperature, humidity, light-levels and motion data. It runs Linux and can do some on-board processing before passing the data on to e.g. busfarhn or COSM.

jump to: the story, How it’s made, Do it yourself.

One can write a story from two angles: a historical account or coming from the motivation. Since my motivation is something like “it sounded like a fun thing to do”, I’ll give the historical account.
The purpose of all this is to put a temperature, humidity, light-level and motion sensor in every room. And while we’re at it, throw in a relay to control a light-bulb. This combination allows some nice home-automation to be implemented. Even further: it provides a test-bed for activity recognition and helps to implement the idea of a quantified self. But in the end, it really just sounded like a fun thing to do.

After I had finished a first version of busfarhn and implemented the central heating control, I wanted to take things to the next level and started working on the SenseLamp. It didn’t take too long to whip up a first prototype: SenseLamp v0.0. It consisted of a TL wr703n, TI Launchpad with an MSP430G2553, a relay module, HC-SR501 PIR sensor and a DHT11 temperature/humidity sensor. All neatly wired up with jumper cables and attached to a lunchbox to which I went to town on with a Dremel. It wasn’t pretty, but got the job done – and it was running for 2 months!

I learned three things from this first prototype:

1. The Linux CDC ACM drivers are buggy: it seems to be a well known problem that the Launchpads serial interface doesn’t work so well in Linux. The reason for this is a bug in the CDC ACM kernel module (see here, here and here). Despite the patches provided, I was unable to fix the issue on the WR703N resulting a bit of instability. A cronjob to reboot the router every 6 hours served as a usable workaround, but certainly does not fix the issue.
2. HTTP only goes so far: using a simple HTTP based interface implemented via CGI worked beautifully for the central heating control as the interface was unidirectional. The SenseLamp however, needs to be able to send sensor data as well. So a different protocol/interface is needed.
3. It will have to look better than this: While the dremeled lunchbox worked fine as a first prototype, I wouldn’t want plastic lumps hanging throughout my flat. So if I was to deploy this on a bigger scale (count > 1), it would have to look better than this.

The next iteration was designed to do away with the flaws of the prototype. To get rid of all those jumper cables and get things neat and tidy, I designed a PCB and sent if of to SeeedStudio Fusion. As much as I favor local production and business – SeeedStudio was simply 10 times cheaper than anything I found in the UK – even with similar lead time. It only took about 2.5 weeks until I got the PCB in the mail, with the cheapest delivery option that is.

The goal for the SenseLamp PCB is to serve as a "shield&quot: for the WR703N router. The shield is powered by the router and directly talks to the routers AR7240 CPU via the serial port exposed via two test-pads (yep, fiddly soldering included). To make the power supply work, the board sports a 3.3V LDO. All sensor protocols required (the single wire protocol of the DHT11/DHT22), GPIO stuff for the PIR sensor and ADC stuff for the LDR are handled by the MSP430G2553 which is also on the PCB. A neat package all in all.

At the same I started playing around with different frame designs. The lamp shade side of things would have to support the boards, mains to 5V power supply (which handily comes with the router), some space for the light bulb and a spot to place the PIR and temperature sensor away from the light-bulb. As I happen to be interested in personal fabrication (sigh) I laser-cut a triangular frame that unfortunately is not really portable across different machines and can certainly not be ordered from services like Ponoko. But then, any other form of shade/lamp holder would do.

I ended up deploying that version in the kitchen and ran it there for a while. It successfully did away with the communication issues that plagued version 0. Also it looked quite a bit better. But it still wasn’t quite there yet:

• forgot the PIR sensor: the lesson learned here is never design a PCB in a hurry. For some reason I forgot to add the the appropriate pinheaders for the PIR sensor on the PCB. So I had to compensate for that while wiring up the whole thing – it worked, but it was messy. Because like this the PIR sensor can not simply sit on the board, it has to be placed somewhere on the frame. Yet another thing to consider.
• assembly was still too difficult: which is in part due to the PIR screw-up. Until this version I assumed I could simply tie it all together using some good old zipties. But as it turns out the holes in the relay board, as well as the router board are close to M2 and that’s too small for those standard 50mm zipties. So, I’d have to put in screws. Combine that with my tendency to pack everything too tight (on the frame) and you end up with something that’s very hard to put together.
• DHT11 sensors are too inaccurate: according to their datasheet, DHT11 sensors have a tolerance of +- 2 Celsius and 1% humidity. That’s quite a lot when one wants to monitor temperatures in the range of 20 +- 3 degrees. So I needed better sensors: the pin-compatible DHT22 to the rescue.

That’s the version that I ended up building four times and putting one up in every room. It uses a new revision of the SenseLamp PCB (taking the PIR sensor into account), has a way cleaner cable structure and sports DHT22 sensors. Let’s see how it’s made in the next section.

Besides the sensors, there are two main hardware components involved: the wr703n router and the SenseLamp board. As the figure shows, the router merely passes through the 5V USB power and provides WiFi – effectively turning a Linux machine into a wifi shield. This is still twice as cheap as buying a dedicated WiFi shield. And as power consumption is not really of concern here, this works just fine.

The router as well as the SenseLamp board are powered from a single 5V power supply, which in turn is powered from the power line which would normally light up the lamp. As a result, existing light-switches effectively turn the whole device on and off and not just the light. I’ve taped something over the light switches to prevent accidentally turning of a SenseLamp.
To connect the 5V power supply (which comes with the wr703n), I solder cables to the plugs of the power supply and wire them in parallel to the light bulb.

This little board does most of the heavy lifting: it provides the 3.3V power supply for the MSP320, connects the relay to the MCU and provides a home for all the sensors. There is a programming port as well, which allows in-circuit programming/testing of the firmware using a TI Launchpad as FET. At some point one may ask: why an MSP430 and not something Arduino-ish? I have two reasons: MSP430s require a lower external part count if one wants stable timings (just a resistor and no quartz), and a TI Launchpad is a lot cheaper than an Arduino or an AVR ISP. In short, the MSP430G2553 just delivers more "bang for the buck" than an AVR, let alone an Arduino.

We’re not using much of the WR703N except for its WiFi, serial port and 5V coming from its USB port. The only thing that’s tricky here is soldering wires to the two testpads, as described elsewhere.

The software side of things consists of two parts: the firmware on the MSP430 and some userland program running on the WR703N.
The MSP430 firmware has to deal with all the sensors and serial communication to the "WiFi shield". Thanks to that awesome project called Energia, writing code for the MSP430 is as convenient as it is with an Arduino (but at a fraction of the cost). The firmware can be found in the GitHub repository.

Having a sensor laden lamp shade hanging around is boring, unless one does something with those sensors. Earlier this year, I wrote busfarhn which is a message bus at the core of my home automation effort. This message bus also sports a GUI module implemented using MetroUI CSS and socket.io.

I’ve written a simple TCP based client that bridges between busfarhn and the SenseLamp firmware. It relays incomming commands and translates the SenseLamp output into busfarhn messages. All of that code can be found in the GitHub repository of busfarhn.

 

DIY

First things first: all SenseLamp material is open source. If not stated otherwise, it is published under the MIT license and can be found on GitHub. Should you be in the process of building one yourself and have questions – I’d be happy to help.
Building a SenseLamp is a straight forward process, involving three main activities:

1. Gathering all parts and components
2. Assembling the hardware
3. Flashing OpenWRT and firmware + installing some userland driver program.

Gathering all parts and components

The part count of a SenseLamp is lower than one might expect. Besides the WR703N router and sensors and microcontroller, only common place parts such as resistors and caps are required. The SenseLamp PCB is single-sided, uses exclusively through-hole components and not too fine traces so that it can be produced at home if necessary. Find a A rudimentary bill of materials can be found here.
I bought most of the components from eBay, RS Components and Farnell. The board was manufactured by SeeedStudio Fusion. It took roughly a month to source all parts – including the custom PCB.

Assembling the hardware

Hardware assembly takes part in three stages:

1. First, all components have to be soldered to the SenseLamp PCB, some wires to the WR703N router (described above), and some thick enough wires to the 5V power supply coming with the router (it helps to drill a hole in the plugs). Then, a "sandwich" is made by stacking the SenseLamp board on top of the WR703N using M2 screws (I drilled slightly bigger holes in the WR703N) and some spacers, which I 3D printed. Once that tower was assembled, I connected the SenseLamp PCB to a 5V power supply, FTDI 223 3V3 serial cable and TI Launchpad to test the SenseLamp board in isolation and program the firmware.
2. The frame is assembled (depends on the kind of frame) and the 5V power supply is added. Try and layout the cables in this stage as well. Add the SenseLamp board sandwich in this stage as well.
3. At last one has to wire it all up. I used luster terminals to wire the 5V parallel to the lamp and ran one lead through the relay, so that the lamp could be controlled from the SenseLamp.

At this point it is a good idea to power it all up and see if everything’s working fine. I used a leftover cable, which I opened on one end and fed the leads into the top luster terminal to simulate it hanging from the ceiling.

Closing remarks

All in all I built four of these puppies and installed them in my livingroom, hallway, kitchen and bedroom. For now I’m simply using the light and motion sensor to automatically turn on the light when its dark. The temperature/humidity data is simply logged away and I glance at it every now and then out of interest. In the future I plan to use them for some light activity recognition and infer my sleep times and similar activities from the data.
Another thing I might do is design different frames as I’m not entirely happy with the current form. The WR703N, as well as the relay module both have LEDs which are constantly on and are slightly annoying – despite their usefulness.

My final remark should be that this was a fun build that took about twice as long as originally anticipated. I spent about two months (spare time) going through the prototypes, implementing the firmware and busfarhn integration. Would I do it again? Anytime.

A few days ago, I’ve mounted a Dremel on my MendelMax using this thing. Such as setup allows for a few nice things: milling wood or drilling printed circuit boards – once you got the software down.
As the scripts are a bit hidden in this post, check them out on GitHub.

Milling wood

Once the Dremel is on the machine, milling wood is pretty much a matter of converting a 2D drawing (e.g. stored as DXF) to Marlin compatible GCode. The weapon of choice here seems to be a program called dxf2gcode. What that program outputs however, is not directly suited for feeding it into the MendelMax:

• comments: comments are surrounded by parenthesis, whereas for this use they’re single-line comments starting with a semicolon.
• feed rate: feed rate is set using an F command (e.g. F400), whereas for the RepRap it should be a G1 expression (more like G1 F400)
• unsupported commands: As the generated GCode is designed for real CNC milling machines, several specific commands have to be issues such as starting the cooland flow or getting the spindle up to speed. As such commands could confuse the RepRap (not checked, just assumed) we should filter them out or replace them with more suited counterparts.
• different movement commands: dxf2gcode produces G0 for initial positioning, whereas moving a RepRap works with G1 commands.
• different use of whitespace: typically GCode seems to be written so that there is no whitespace between the code character and numeric data. dxf2gcode however, produces whitespace where they typically aren’t. That whitespace makes the output look nice, but again might not work so well with a RepRap.

All those steps are implemented in a little script on GitHub.

Drilling PCBs

Drilling PCBs is something easy to do at first glance. It turns out, however, that aligning the layer mask with the drilled holes is a delicate issue. So far I’ve achieved the best results using the following steps (in that order):

1. Export an excellon drill list from EAGLE using the CAM Processor excellon.cam script
2. Convert the exported Excellon file (probably ending with .drd) to GCode using this script from GitHub.
3. Drill the holes using the generated GCode
4. Print the mask, cut it out and align it with the drilled holes
5. Transfer the mask (toner transfer, UV exposure) and etch the PCB

Converting the Excellon drill file is a key part in this process. The script linked above does just that, including mil to millimeter conversion, and starting point selection. Personally I tend to identify a certain point on the board with the starting point of the printer. See the help output from the script below for a list of what it can do.

Usage: gcodeutils/excellon2gcode.rb [options] drillfile.drd outfile.gcode
    -s, --start STARTPOINT           The start point of the printer, format [XX]x[YY] [mm]
    -f, --first FIRSTPOINT           First drill point to go for and equate to zero, format [XX]x[YY] [mm]
    -m, --mil2mm                     Translate units from MIL to MM
    -i, --invert-xX                  Inverts the x axis
    -t, --travel-height HEIGHT       The travel height in mm
    -d, --drill-height HEIGHT        The drill height in mm
    -r, --rotate ANGLE               Rotates the holes by ANGLE degrees
        --preamble FILE              Prepend the preamble from FILE
    -p, --postamble FILE             Append the postamble from FILE
    -v, --verbose                    Produce verbose output
    -g, --gnuplot                    Plot the drill holes on the console
    -h, --help                       Display this screen

On a side node, try not to move the PCB while the drill is still in the board – it will snap. Obviously -.-

Today I finally got around to try printing cookie dough using RichRaps paste extruder on my new MendelMax (a post about that awesome machine is bound to follow).
At first glance, printing 3D structures with cookie dough seems to work just fine. However, I encountered several issues:

• losing shape while baking: at this point this is probably the most severe issue. No “object” I printed survived the baking intact. All of them melted down to an unrecognizable blob – most likely because of the high butter content of the dough. It seems that it is the butter that provides most of the structural integrity and said structure is obviously gone in the oven.
  
• getting the prints to stick to the print bed was problematic as well. My first attempt was with baking paper, not the brightest idea in hindsight as this stuff is designed to be grease-proof. The second idea was to use aluminium foil (in accordance to RichRap) which worked slightly better. Getting the Z height right and having a perfectly level bed – which I don’t have yet – seems to be key here.
• the size of the syringe severely limits the size of objects that can be printed, considering the nozzle diameter of 2mm. This is not a problem specific to printing cookie dough, however it’s not that much of an issue with other pastes as they may permit the usage of a needle.

Printing flat objects works reasonably well. Starting with RichRaps “Masa Slic3r config”, I played with different infil-patterns to achieve the look I wanted. A rather moderate infil of 10% did the trick, as the dough will merge into one coherent piece in the oven.

Cookie dough seems to be an unsuitable printing material as it is completely unsuitable for maintaining any shape when exposed to heat. There are more traditional recipes that involve sculpting the cake/biscuit. They might be worth investigating.

In summary, it was a great first print for this new machine and made want to look into alternative print materials – next up is ceramic clay. And some day I might even print PLA on my new machine.

This algorithm is something a friend of mine and I have developed quite some time ago (probably a year or so). It might also be already known under some name and I’m not aware of it. None the less it’s an interesting solution to a quite interesting problem.

Suppose that you wanted to generate the words of the alphabet . And that you wanted to do that in a parallel manner, such that you had a set of threads where each thread has a unique number out of assigned.
In that case it would be favorable to have a mapping in the form , so that each thread could easily (reading with less computational effort) generate the word it’s supposed to work on. Notice that implicit definition of .

To solve the problem described previously, we start with a function that maps elements of to points in an -dimensional discrete hypercube. That mapping is defined as follows: where . This mapping obviously maps a natural number to a point in a discrete -dimensional hypercube with an edge length of . Example: Consider and . Then we can visualize as follows:

Now that we have a mapping from a natural number to a point in the hypercube, we need a mapping from a point in the hypercube to the word itself. Such a mapping is easy to find. Consider where the are the components of the vector and .

So our final mapping is and exactly what we desired. One might notice that must be surjective so that each word is computed if there are just enough threads. To prove that, we’ll prove that as well as is surjective (since the functional composition of two surjective functions is surjective as well).

Theorem:	is surjective, so that .
Proof:	Let , , and . Assume that , then (1) (2) (3) The transition from (1) to (2) is allowed as . Similar goes for the equivalence of (2) and (3): as .

Theorem:	is surjective, so that .
Proof:	Let then the vector (which obviously fullfils ) must exist, since and .

So the mapping is surjective and does exactly what we want. I consider that solution to be a particular elegant one and wanted of post it for about a year now. Finally I found some spare time to do so. If you use that solution, find a mistake or find it somewhere else (maybe even previously described) please drop a comment.

In the past few months it has become quite on this blog. That’s not because I wasn’t involved in any activity, but rather because I was too involved in one (building a quadrocopter). During that particular activity we started using a logic analyzer. There is a great open source project building such a device (originally here). Unfortunately for quite some time it was out of stock. So we set on to build one ourselves. In that process I started writing some client software for it, since there was a lack of extensible, open source, logic analyzer client software. In the meantime, the Open Workbench Logic Sniffer was in stock again. So we ordered two of them. At the time they arrived, the LogicAnalyzer was pretty much usable.

While designing the LogicAnalyzer, I had three major goals in mind:

1. Extensibility: integrating new devices should be as easy as possible. Generally speaking, integrating any kind of data source should be easy.
2. Clean UI: some logic analyzer client software that is around has a pretty cluttered UI. The LogicAnalyzer UI should be clean and intuitive.
3. Architecture: in order to achieve the required extensibility and to enhance maintainability, a good and clean architecture is required.

All goals have been met (although one might discuss how well goal three has been reached – that’s in the eye of the beholder).

LogicAnalyzer is built using the Eclipse Rich Client Platform. This powerful platform provides mechanisms to extend applications built using it. So we’re using the extension point mechanism of Eclipse to provide the required extensibility. Special focus has been put on a clean API and unobtrusive interfaces. By using Eclipse RCP, we also gain multi-platform support. LA runs on Mac OSX, Linux and Windows.

The clean UI is achieved by only showing what’s currently required. When you open LogicAnalyzer, all you’ll see is the button to get you started. The tools integrated into the program may require a UI, which is only shown when they’re selected. We wanted to maximize the amount of pixels available to show what’s really important: the data we’re visualizing.

An important (but simple) rule during the design phase, has been a clear separation of concerns. Thus we’ve clearly separated UI from business logic. Most components are connected using Eclipse mechanisms (e.g. extension points). A lot has been designed against interfaces (where appropriate). Those measures resulted in a clean structure and good maintainability.

If you want to know more (such as a list of features) or want to give it a try, I recommend that you have a look at LogicAnalyzers homepage. Some numbers for those interested: the initial commit was roughly 10k lines of code written in two weeks. Still, so far we’ve experienced only few (known but unfixed) bugs.