A milestone

Too bad I work alone and mostly at nighttime. Otherwise, I would have some people around to share the sheer joy that I am experiencing right now. For a lack of that, I’ll turn to the web. Just an hour ago, I completed a major milestone in my main project line. I am ecstatic as with work of this magnitude, the light at the end of the tunnel is always months away( and right after, you get into another tunnel…) Here is the writeup on the situation.

I have had a fascination with oscilloscopes for a very long time. While being incredibly useful (for those who are into electronics that is), they have a mysterious sense to them that still gets me after all those years of hanging out with complicated machinery. I remember clearly seeing rows and rows of them during my first university year, having only a very rough idea of what they were for but still knowing, judging by their numbers, that they must be very useful for every electronics bench to get its own. They are what epitomizes the knobs and dials (screen in this case) strange and obscure apparatus of the modern age.

So much so that I decided to program one from scratch for my final engineering project; I had very ambitious plans for it. The electronics would be managed by a Microchip PIC18F4550 – a USB microcontroller – and the application on the host PC would be programmed in C#. Its killer feature would be that its display would be 3D, giving the user one more dimension for visualizing, combining and probing waveforms. Turned out implementing the USB stack was a major bitch (should have used Microchip’s ready-made one…) so I decided to get signals through the sound card input. No big deal, the main application was agnostic as to where its data came from. Then, the 3D part was a huge headache too (80% of the code, a primitive but complete 3D engine), but I got trough it and in the end it worked well enough for a public showing. I will post all its code and some screen shots when I find the motivation too, but for reasons that will be developed upon at this time, I decided no to further its development. Simply put, I had discovered the world of Open Source and realized that platform-locking my project (DirectX, .NET) was not inline with my philosophy of getting good electronic tools in the hand of the masses.

This new one is implemented on an OS of mine (Elements, but beware, the post is very outdated) and thus completely web oriented and RESTful. The user interface is described in XHTML, SVG and JavaScript with all of it getting served along with the oscilloscope function by an ATMega328p with 32kB of static EEPROM storage. That’s a web server, TCP/IP stack, a file system and oscilloscope running on 32kB of Flash, 32kB of EEPROM and 2kB of RAM embarked on a 16 MHz chip! It had been a web server for quite a while, but tonight, I got it to behave like a usable oscilloscope. I am a happy man…

CMoy headphone amplifier

The final product

One of my friends, who creates music as a hobby, recently bought a pair of AKG 601 headphones. While I do listen to a fair amount of music, I would not consider myself an audiophile or anything close to that. However, those headphones do make a difference I can notice in the quality (or lack thereof for low bit rate MP3s) of whatever is being played. There is only one small problem with them. Being massive open headphones, my friend’s sound card is only able to put out an acceptable level of sound at maximum volume; his MP3 player, on the other hand, is simply incapable of driving them. The AKG 601 have a rated impedance of 120 Ohms while normal earbuds seem to be around 20. As a result of a soundcard’s output impedance being too high, a normal speaker output  is not capable of providing enough current to the headphones.

They are huge, expensive and leak a lot of sound, so he does not plan to use them on bus rides, but there are still some serious downsides with having to drive them at maximum volume:

  • Levels of distortion increase significantly as maximum power is reached in an amplifier. This means that running the volume at maximum produces sound of a lower quality than if it was outputted at 50% and then passed trough a more capable amplifier.
  • When he creates music and wants to listen to specific instruments or tracks that are not as loud as the rest he is stuck with the current level of volume.

To address those problems he was considering purchasing a headphone amplifier, but to me, this seemed like the perfect opportunity for a diy solution. As he is not at all familiar with the world of electronics, I offered myself for the task as it was a good and easy way to get my hands dirty with pure analog stuff and get acquainted with audio. My background is more software with the occasional digital circuit. I did learn about all the concepts in application in this project at school, but the retention capacity of my brain decreases significantly when the interest is not there, and a bunch of formulas splattered on a white board does not tell me how to use an op amp in real life.

Since parts are cheap and shipping isn’t, I decided to build one for me as well. This post details the process but its not a how-to for the CMoy as there are alrealy a ton around the web.


I started my research on the excellent diyaudioprojects.com and found the CMoy/Grado RA-1 project. The circuit looked simple enough and according to the author, the quality was on par with a Grado RA-1 which retails at 425 $US on amazon. It turns out that the CMoy pocket amplifier, named after Chu Moy, its inventor, is a very popular design. You can find kits for it on the web that are about an order of magnitude cheaper than the RA-1 it aims at emulating.

Amplifier circuit

Chu Moy’s website provides a wealth of information, but the one that help me the most by far was Warren Young‘s tutorial on the CMoy.

Do not let yourself be fooled by the simplicity of this circuit, there is a lot more to it than meets the eye and tangentsoft’s tutorial does an outstanding job at explaining all the specificities  and what you need to be concerned about when making modification. It took me about ten minutes to get a working version on a breadboard, but actually understanding it required a fair amount of reading and thinking. Once again, Warren’s site proved ato be invaluable resource in this, especially his audiologica section. Some amplifier designs on his website are considerably more complex than this one and would be a nice progression from this project.

Power supply circuit

The power supply is no too complicated but somewhat unconventional because of its use of a virtual ground, something that was previously unknown to me. My design is generally the same except for the addition of a linear regulator and a protection diode as I did not want to run it from a 9V battery and the wall wart I had lying around was unregulated. For the amplifying part, I added a resistance in parallel with the volume pot to make it behave in a more linear fashion (I bought a log one), some decoupling ceramic caps for the op-amp’s supply lines and upped the value of C1 from 0.1uF to 1uF to let trough lower bass frequencies. Every CMoy amplifier circuit variation uses different resistance value. R2 is fairly constant at 100kOhm as it forms toghether with C1 a high-pass filter. R3 and R4 will vary depending on the gain required. The power supply part is pretty straightforward but you will need to find a value for R2 and R3 that will strike a good balance between not draining the battery too fast (should you choose to go that route) and providing the virtual ground enough current sink capability.

Power consumption is very low. I am using a 9V unregulated wall-wart with a current rating of 100mA. Since the amp cannot load it fully, the output voltage at the connector is around 12V which leaves plenty of room for subsequent regulation down to 9.5V. The linear regulator is an absolute necessity as its omission lets trough a very audible hum.

While this circuit will work with any standard parts (which I used for the prototype), it is best to use audio grade components. This is often synonym of overpriced, but in this case, since we are talking small and simple, you can get away with only investing a few more dollars. For the op-amp, I selected the  Burr Brown OPA2134 as recommended by CMoy and decided to go with polypropylene metal film capacitors instead of polyester. I also got a gold-plated IC sockets and audio jacks. The only non-standard part was the volume pot, which had to be dual-gang in order to control both channel at once.


On the breadboard
Protype with generic components

Naturally, everything stated on a bread board. There is nothing spectacular about that, but when I first put toghether the circuit, all I had to work with was some general purpose op-amps (MC1458) and some electrolytic caps. I was unsure whether the op-amp would be sufficient or not, but I did know electrolytic caps are only to be used in a bypass configuration as they induce a fair amount of distortion when used in line. Regardless, there was improvement in comparision with not using an amp at all. At this point, I became confident this would not be another useless circuit and things could only get better with the “audio grade” parts.

Prototype with audio-grade components

When I received the components I ordered from mouser specifically for this project, I instantly swapped them on the protoype and was rewared with a increase in quality… or so I think. The term “subjective” applies especially well to the audio realm; due to known psychological effects, me knowing the components were actually better in theory rendered me incapable of judging whether there was an improvement or not. Then again, I do not really know what to look for but I would consider the overall difference to be subtle enough to be affected by skewed perception. This is why I decided to take my friend trough some blind tests. He does not know a capacitor from a resistance and much less their potential effect on sound, on the other hand, he know music and most likely has a more discerning hear than mine; he is the perfect candidate. More on that at the end of the post.


The original box

While the parts were on their way, I decided to get started on the enclosure right away. Naturally, I would have gone towards a plastic project box but while me and my friend were discussing the project, he suggested the use of a small wooden chest as he had one handy and felt a tupperware container would not do a piece of quality audio equipment any justice. Upon inspecting it, I figured it would be pretty easy to turn it into something visually pleasing with a bit of woodworking. I found my box at Michael’s for $3.50. I had never worked on wood (except while renovating but I would not consider this woodworking) so I was somewhat unsure of the end-result. With perspective, this is the prettiest project enclosure I have built so far and for that price,  I’ll definetly repeat this design.

The box went trough several modifications. First, the lid was removed and disassembled. The rectangular pieces of which the sides of the lid were made were cut and glued to the box. Two there added to the opening of the box to provide a bit more support for feets while the two others where glued to the bottom to raise the pcb.

The holes and marks where the hinges and lock used to be were filled with wood filler and then the edges were sanded down to give the box a rounder shape. Lastly, holes to accomodate the various connectors and holders were carefully (pine is very soft and chips easily) drilled.

Since the box was made out of pine, it needed to have wood conditionner applied on it. It took me a while to figure out how to use this product as information from some diy sites conflicts with the manufacturer’s label and everyone seems to have their particular process when it comes to preparing soft wood for staining. I finally came across a site that explained that wood conditionner was actually diluted varnish. Consequently, it needed a day of drying to properly seal the wood’s pores and allow even stain penetration. This contradicted the can’s label which directed to apply the stain within two hours of applying the conditionner. I ended up following the website’s advice and let it dry overnight. The stain came out beautiful and uniform without any blotching while tests using the manufacturer’s instructions on scraps where not so conclusive.

After staining, I applied two coats of polyurethane warnish with some light sanding in between and that was it for the box. It took three days including drying time but overall, I would estimate the amount of time invested to two hours with sanding being the longer task.


Soldering the circuit was somewhat harder than usual because of the PCB I used but with any

Circuit in fabrication

standard board this should be an easy task. The routing is straighforward but ideally, everything affecting the signal path should be kept as close as possible so as to avoid the side effects of long wires (inductance, capacitance, EMI pickup). Mine required a fairly sized board because of the polypropylene capacitors, but with small components, everything should fit on two postage stamps and not take more than two hours to solder.


To block any unwanted EMI, I lined the inside of the box with two layers of aluminium foil glued toghether like Mark did on his CMoy/Grado RA-1 project. Whether this is useless or not I cannot tell, but it certainly cannot hurt. I still have some old CRTs at my parent’s place so when I get the chance, I will try and see if it picks up anything.

Fitting everything inside the box.

Installing the circuit in the box is no simple task as all the connections have to be soldered while it is in there sitting in mid air. Incidently debugging also has to happen in this position. Mine did pass the smoke test but it did not work correctly the first time around. It turns out I had soldered one channel of the pot the wrong way.


As mentioned in the intro, I would not consider myself versed in the art of listening  and I much less have the capacity to describe sound with words. However, I can certainly tell it makes a noticeable difference in quality of the music. Even with my old and battered Koss headphones it sounds better but when I got to try it with my friend’s AKG-601 I was blown away and felt for a minute I should make the investment and get myself a pair.

The downside of better sound is more obvious compression artifacts; a good amplifier will not discriminate either. Some of my tunes which sounded fine on my MP3 player with earbuds are now barely listenable because of the effectiveness of the amp at reproducing what it takes as input. I finally got a around to finding a few MP3 in my collection which were of good quality, but you should nonetheless be aware that if the end product sounds bad, check the MP3s first before probing the circuit for a problem that isn’t there.

I have only listened to it for a few hours so far and apparently, it get’s better with time as parts burn-in (like engines??). This seems odd to me, but I will take the web’s word on that. I could somehow see this phenomenon coming into play with tubes and high-powered solid-state amplifiers as they are genereally under a lot of thermal stress but for this little mW scale headphone amp, I have my doubts.

(Scientific) Test

Yes, it does sound better, but that’s only my opinion. And a very biaised one because I researched and built the whole thing and incidently, would be very disapointed if all that work did not pay off. It certainly feels like adding the amp to my listening set-up improves the sound, but you can only live with a placebo effect for so long, so I got two friends including the one for which this project was started in the first place and did a blind test.

There were initially four configurations but we decided to drop one  for fear of not completing the test before the beer store closed:

  • Straight MP3 player
  • MP3 player and prototype circuit (no audio-grade components)
  • MP3 player and finished amp

The headphones were obviously the same for all tests and the volumes were adjusted to approximatively the same level. The MP3 player when used alone had to be set to its max volume which is a good thing since the whole purpose of the headphone amp is to avoid this as it dramatically increases the distortion level.

A run would consist of 1 minute of listening to the same song (Californiacation by Red Hot Chili Pepers; everyone I know likes this song) on every configuration. The subjects did not know which one it configuration they were listening with, all they could see was me shuffling wires behind a box and then handing them the headphones. We repeated the run three times so as to increase the chances of getting a statistical significance.

One subject got discouraged in the middle of test, complaining that it all sounded the same to him but despite his lack of faith and to his amazement, the results confirmed the predictions. In order of quality:

  1. Prototype
  2. Finished amp
  3. MP3

The rating scheme was a sort in order of preference, but one decided to rate using half marks so the results group the two amps closer toghether. The MP3 player was identified as worst every time while the two amps shared the top two almost equally. I would have expected the finished amp to come out first but after some careful listening to the actual track, I realised compression artifacts were more audible on it. This is probably due to the OPA2134’s better bandwith as artifacts are generally found in higher frequencies. The MP3 player just by itself did sound truly awful, Some artifacts were not present while others were exacerbated but overall, it felt a bit like listening to the FM radio.



Simple, quick and inexpensive projects are definatly a rare occurance in my life, so this one was definetly a welcomed breath of fresh air; its nice to finish something and it gave me a break from battling with C++. It is not perfect yet but when I get the motivation, I’ll get to correcting the small bugs: mainly a minute discrepancy between the left and right gain (resistor/pot variation) and a not linear enough pot. For the time being I’ll just enjoy it as is.


Building audio equipments is definelty something I will revisit in the future. It’s a break from routine and a very gentle way to get familiarised with the mysterious and unpredictable field of analog electronics: everything works at a low frequency and a low votlage so you can be confident nothing extra weird is happening. As a plus, you get something useful at the end of the day. To summarize, this project is the perfect “Hello world” equivalent.

Next step will be a full scale amp with some digital controls; the circuit is putting itself toghether in my mind as I write those lines, but it will have to wait for a while as I have other stuff that needs to get finished and still in the process of salvaging components.

My friend’s version

My friend's CMoy amp

Not that different actually, but it took a while before we could meet (with 500 km separating us) and sit down for a few hours (from 20:00 to 04:00) to finish the project. I had given him a plan and a solder iron, but we ended up completing the project together. In retrospective, there was no way he could have worked on the thing like I hope he would; I even had soldered the voltage regulator backwards and besides that, there we a massive amount of obstacles I strongly doubt someone with no electronic background could have overcome. Still, it was fun getting high on solder fumes along with him. Tests were conclusive and he is now the proud owner of a clone of a 425$-ish amp clone. The one thing we changed was how the volume pot behaves. I had originally bought a log version but found out it was only useful at 80% of its range so I added a couple resistors to make my friends’s pot behave a bit in a more linear fashion.



I really enjoy putting a lot of thinking in the gifts I give. Apparently, its the gesture that counts, but I feel a gesture and a thought are worth much more. Buying a gift for the sake of buying a gift is just like calling the plumber to get a leaky faucet fixed, you pay someone/something to take care of a problem for you. On top of that, useless gifts too often end up spending a few years at the bottom of a closet and then get thrown in the trash during a session of spring cleaning.

So the ideal gift should be something into which a lot of thought was invested in, be it in choosing, finding it or building it. It not only has to mean something but it also has to remind of the giver.

This Christmas, I built (with the help of my mother and my other sister) a light box for my little sister. A picture is worth a thousand words:


Basically, its a table top studio. It diffuses light around the object so as to diminish reflections and shadow as mush as possible in order to capture the object itself rather than it and its environment. There are plenty of tutorials to make light boxes on the net so this is nothing I invented myself, but I did design this one to be sturdy, customisable and portable.

My sister’s camera is a bit crappy and virtually no post-processing was applied to the pictures, but I can say I am more than satisfied with the result. Here are a few demonstrations of what it can do:

This is a good old reflex camera from the 80’s

Handpainted figurines from a tabletop game called WarHammer 40k. Those are 3cm high.

An ATI Radeon 9800 pro.

A sandwich bread; this one was eaten yesterday.

The Elements framework

This is another project I have fun on while I get a bit of spare time from having no life. It has actually been in the works for quite a while but I have just recently started the actual programming (in C++). It is called the Elements Framework. Despite being just another tool for myself, I have had a few friends who expressed interest into knowing a bit of details about it. Since I cannot precisely really formulate what it is myself, I though it would be a worthy exercise to write a short description of the framework. Now you might be asking yourself, how the hell can you not know what you have been working on for the past year? Well the answer is: when I think, I do not necessarily use words, I use ideas, I use examples, I use chunks of code, I use drugs, but since I do not work with verbal constructs to begin with, explaining what I do is somewhat tricky because I have to compile a bunch of concepts into correctly formed sentences. Something I can normally do just fine with everyday objects and concepts (I am not speech impaired), but when it concerns software architecture its philosophy, it gets hard, especially if your interlocutor has no clue as to what HTTP really is.

The idea.

The Elements Framework has one simple goal: apply the philosophy of the web to traditional software. Sounds far fetched? Let me explain. The web is to me one if not the greatest of systems created by men. It has not failed once since its inception, it has seen worldwide acceptance within only a few years, it’s easy to use and it’s actually shaping the future of mankind at a rate never seen before. In fact, it is so ubiquitous and important that it is called “The World Wide Web”. Do you know any other system that got popular enough to get the “World Wide” prefix? I don’t. But above all, the workings of the Web are blindingly simple; it is built upon a principle called REST and relies on only two (RESTful) protocols to function: HTTP and DNS (Maybe WAKA soon…)

Before we move on, let me define one crucial thing: the Web and Internet, even if the two terms are often interchanged and refer to the same entity in popular speech, are not the same systems. The Internet is TCP, UDP, IP, ARP, MAC and a bunch of other protocols. In other words, the Internet is everything below layer 5 of the TCP/IP protocol suite. The Web is just HTTP and DNS. Although HTTP is most of the time tunnelled through the Internet, it does not require it to function. HTTP only assumes an error-free transmission, and TCP is the provider of this service in the case of the Internet.

Now, what the Elements Framework will try to achieve is making software systems that run on it behave just like the Web as well as being part of it. Let me develop on this:

  • Out of the box, you will be able to “browse” your software system just like you browse a website. In fact, that software system will look exactly like a website. This means that every component will provide its own HTML (of any other markup language) page for users to check and interact with. Through this, it will be possible to build rich user interfaces through the use of javascript, CSS and whatever other markup and styling language. This also means that every web browser will be able to display those interfaces, be it on a *nix, Windows, Cell-phone, etc. True to the REST philosophy, the server provides a representation of the resource and the browser decides how it displays it. Humans will be able to inspect systems and get a sense of how they work just like they can do with websites since the architecture of the system will be an exact match of its apparent organization as seen from the web.
  • An Elements system and its components will be naturally distributable, just like the Web. So now, the keyboard, the microphone, the screen, the XML parser and the neural network can be anywhere there is connectivity. If one becomes unavailable, ask Google for another…
  • Interaction will solely happen through HTTP. Since the interface will be standard, it will be much easier to connect heterogenic components together, just like Mashups. Moreover, every component of an Elements system will be able to expose its interface to the rest of the world if it wants to.
  • The Elements framework wants the web to be a “Web of things” where every single piece of electronic equipment can be connected to it if needed. To achieve that, it will be made as lean as possible in order to function on the smallest microcontrollers. Imagine every electrical switch and outlet in your home being accessible through your browser? Every home would have its own web, shielded from the WWW of course.

How it works.

The basic construction block of an Elements framework is, as you have guessed it, an Element. The active part of an Element is called a Resource. Simply put, a Resource is a lean HTTP server. It takes HTTP messages, checks the URL if the message was for itself, or forwards it to its children if it is directed to them. If the message was its, it processes it. Take for example three Resources, res1, res2 and res3 with res2 and res3 being children of res1. If you want to direct a message to res2, the message’s address would be /res1/res2/ . res1, just by receiving the message, would know it was the intended recipient (we trust DNS and TCP to get stuff where it is suppose to go), so it would look for the url of the message for the next recipient: res2. Turns out res1 has a children named res2, so res1 would then happily pass the message to res2 who, upon analysis, would figure out it is the final recipient because there is nobody after the last “/”. res2 would then process the content of the message and take appropriate action, like sending a response to the originator if the message was a request or turn on a light fixture in your home.

The other elemental building block of an Elements framework is the Authority. Authorities implement concurrency in the Elements framework and are responsible for a whole lot of other things (hence their authoritative nature). They also have everything a Resource has because they inherit from it so for this short description, there is no need to explain more about authorities.

As stated earlier, an Elements system is just like a website. By assembling a bunch of Resources together and by providing them with the amount of specialization required for them to have a bit of intelligence, we can actually build more complex systems that behave like websites. For example, let’s look at what the organisation of a calculator would look like. Mind you this is a rather simplistic because programs as simple as calculators rarely get componentized.

  • Calc/
    • Parser.Calc/
    • Add.Calc/
      • /Left
      • /Right
      • /Result
    • Mul.Calc/
      • /Left
      • /Right
      • /Result

When the user directs his browser to http://Calc/ (with an HTTP GET request), he is presented with a webpage (the representation of http://Calc/) containing a simple form: a text box with on its right a button that reads “=” and some instruction text (or images, publicity, whatever you could put on the WWW). Through reading the instructions, the user promptly figures out how this calculator works and proceeds with doing some math. He types a mathematical expression (5 + 7, 125 * 8, etc.) in the text box and then presses “=” to expecting the result to appear on the right of the button. Upon clicking on the “=”, quite a lot will happen in the Elements framework.

First, the user’s browser will send an HTTP POST request to http://Calc/ . When the root Element (whose name is Calc) receives the request, he analyses the header and deducts that he is the intended recipient and that request is actually a user that needs to do some intense computations. Calc is somewhat lazy; his job is just to display the calculator, not to do the calculations. He then proceeds to build another HTTP POST request and sends the expression he received to http://Parser.Calc/.

Parser receives the request, figures it is for him and then proceeds to decompose the expression. “3 + 6” is two values and one operand, so Parser now packages two HTTP POST requests. He sends one containing 3 to http://Add.Calc/Left and 6 to http://Add.Calc/Right, waits for the responses and then sends a HTTP GET to http://Add.Calc/Result/ who then returns 9 as a response. Parser then packages the 9 in an HTTP response and sends it to Calc who then re-renders a representation of itself, but this time with the result of the computation.

Neat, it took a massive amount of HTTP message producing, passing and parsing for something that could have been done in a single assembly instruction, but it was just an example. However, the Resource Calc could have been instructed to use add.computations.co.nz (In New-Zealand) as an adder, it would have made absolutely no difference. Also, imagine that Parser is for some reason unavailable and the user of the calculator does not know where to find a working one. Other Parsers on the web, being web pages, can be indexed by search engines; all the user needs to do now is search the web for a working parser, instruct calc to use it and he is up and running again. This, of course, could have all been automated in order to get one hell of a resilient calculator.

Should the user becomes curious about the inner workings of the calculator, he is always free to go check out the Resources that compose it with its browser, they are all HTTP servers after all so they have to. An HTTP GET on http://Add.Calc/ could for example return a page that explains a bit about what this adding Resource does, display an overview of its state (does it need an oil change anytime soon?) and give links to Right, Left and Result. Or it could be that the calculator is in fact configurable, and at http://Mul.Calc you can find options to return different format of numbers.

That concludes the example. If you browse a bit, you will realize that this kind of thing is already possible with current technology, it is in fact done every day through the use of Web APIs. Using the web in such a way is what the Web 2.0 is all about and is only a natural consequence of RESTful architectures. If you want something more like this framework, the closest thing I have found is Java Servlets. I have actually never used this technology myself but I imagine that Servlets will not run on a microcontroller with 1kB of RAM; at least the java virtual machine wont. What I am trying to achieve is to make the leanest possible HTTP server so it can be used on any platform; the smallest computers could only have one simple Element while a modern day computer could host tens of thousands. After that, developing more complex systems is just a matter of assembling Elements together. The URLs topology you use to browse an Elements system is an exact representation of the architecture of the system. If the components of a system entertain a relationship that is somewhat similar to tree, where some are responsible for others then I think that system can be made to use the Elements framework.

So if you want a real-life running example of an “almost” Elements system, the Tree Framework (If you develop programs you are cool, but if you develop frameworks, you have attained a higher degree of coolness) on which this website runs is one.

The Elements Framework is still in the forge. When I get a working version, I will make it available as open source software. There are many other projects in the pipeline that will use the Elements framework when it is done. Below are a few examples, maybe they will give more down-to-earth examples of what you can do if you apply REST to classic software making:

  • A home automation system, where every outlet, switch and thermostat is accessible from the web and controlled by an Elements system sitting on a server in my house.
  • A web-based oscilloscope and logic analyser.
  • A web content management system based on the Elements Framework.
  • An alarm system.

You can follow developments right here, as children posts of this project post entry. Until then, go create something!