was successfully added to your cart.

Monthly Archives: October 2015

Color choices

By | LightSaga | No Comments

Because a lot of the people that ordered their LightSaga prototype weren’t sure which color to pick, as it is hard to picture how it will look, we asked Aldor to help us out by making one of the small rings in each of the four colors we were going to offer. Wouter and myself already knew we were going to go for polished black (which is like a black glass look) for our clocks so we also had two of the big rings done in this color. Because this choice requires a lot of handwork it is slightly more expensive then the other three, but it has a unique look and feel.

All the results were stunning and it is hard to capture the real look and feel of the rings on a photo, but we tried. The four options we are offering to our customers (or to the enlightened people that will get a LightSaga asap, pun intended):

Glossy Black


Matte Blank (not to be confused with Matt Leblanc)


Matte Blue


Matte Black


Allow me to Interrupt

By | LightSaga | No Comments

Recently I had some problems with my I2C brightness sensor on my clock. It messed up the main routine of smoothly drawing the clock at a rate of 30 updates per second. Analog was a solution to this, but it didn’t solve the main problem of the design. Interrupts where¬†the way to go if I wanted to solve this properly.

So, what is an interrupt in this context? Well, there is a method by which a processor can execute its normal program while continuously monitoring for some kind of event, or interrupt. This event can be triggered by some sort of sensor, or input like a button, or even internally triggered by a timer counting to a particular number.


With an interrupt, the processor temporarily interrupts it’s normal routine to handle the interrupt. It will effectively save its execution state, run a small chunk of code (the interrupt handler or¬†interrupt service routine) and then returns back to whatever it was doing before. How does it know what code to execute? This is set up in the program. The programmer defines where the processor should start executing code if a particular interrupt occurs.

Arduino’s tend to normally only support external interrupts, which is not something I wanted. What would solve all my problems is just being able to run whatever code I’d like (such as I2C readings and fetching internet data) while my clock rendering is guaranteed to run at specific times. After a while I finally managed to hookup an interrupt to a timer the Spark Core provides and after flashing it, it works like a charm! Need to change my power on and off routines a bit and the notifier routines, but this is a vast improvement over the mindless loop my code was doing before.

[su_youtube url=”https://www.youtube.com/watch?v=7Q30Nph9aAQ”]
Limited number of prototype run LightSagas now for sale! I WANT ONE!