## Saturday, December 11, 2010

## Monday, November 22, 2010

## Friday, November 19, 2010

### Mini Word Clock Available Online!

Alden is a contributor author to Make Magazine and a founding member of HacDC.

## Tuesday, November 16, 2010

### Kickstarter projected launched!

Anool has fixed the design files and we are ready to do another board run. Want one? Sign up at Kickstarter.com. Don't want one,but want to see us succeed anyway? Then please tell a friend.

http://www.kickstarter.com/projects/252714519/clockthree

Thanks!

Justin

Don't miss this super cool ipod watch thingy either!

## Saturday, November 06, 2010

### Square Pegs

The set of holes on the right has been drilled out to accommodate the square leads of the LED. Compare those to the set of holes on the left which are the original size.

Anool is drilling out one board (over 700 holes) and we are getting the rest drilled at the factory (thousands of holes). The only problem is that we loose the connect through the board and will need to solder on both sides. Hope Anool can get a board built up this week and test the rest of the circuitry!

Rev two anyone?

## Friday, November 05, 2010

## Sunday, October 31, 2010

### And now something new from the Overkill Department ...

## Thursday, October 28, 2010

### ClockTWO Simulator

This Python simulation with py2exe executable (to use: unzip, double-click dist/ClockTWO.exe) implements the same data structure that ClockTWO uses, so I can see if I am getting all the bits manipulated as I expect.

Controls to set the time:

s -- forward one second

S -- backward one second

m -- forward one minute

M -- backward one minute

Please download, test, and provide feedback.

## Friday, October 22, 2010

### First Road Test

To that effect, Nat Dyck (college roommate) and I built up a Lego swing for the SharkFin. The swing allows the SharkFin to rotate while keeping the accelerometer at the center of rotation. Thus, the pitch measurement from the Accel. should be uncorrupted by the motion.

The second picture is a long exposure to show the center of rotation. It is not spinning nearly as fast as it looks.

## Sunday, October 17, 2010

### Gyro Calibration: Done.

Ok, so it has taken me eight months, but I finally have the SharkFin gyro calibration figured out. This should have been a simple task, but several technical issues combined with summer fun held up this project.

Recall that the SharkFin is a wireless helmet mounted inertial brake light for bicyclist. MEMS (read tiny) instruments measure accelerations and rotations to determine if the brakes are being applied and light the rear facing LEDs. Since the Bar End Brake Light and Amy's Brake Light were mounted directly to the bike, tracking the forward direction (against which braking is measured) was fairly simple. But sensors mounted on the helmet make it much more difficult, since the rider is constantly looking around. We (Anool and I) added a gyro, which measures rotational rate, to help keep track of the forward direction as the rider moves his head. We had some issues with our first analog board, but were able to substitute the SparkFun Razor 9DOF sensor board for the troubled sensors.

The trouble is that the gyro measurements are affected by temperature (and other things) that are not being measured, which impacts the knowledge of the forward direction enough to either shine the brake lights when no brakes are applied or to not apply the brakes under hard braking: two bad situations.

On a bike, light braking is about 1/20 G (where 1G is the amount of acceleration on the surface of the Earth due to gravity). In order for the SharkFin to work, the calibration needs to be accurate down to about 1/100G or about 10 cm / sec^2. This is a sensitive measurement for a dynamic platform. This magnitude of error would be caused by only 1/2 degree error in the pitch estimate.

Luckily, the onboard accelerometer can be used as an external rate measurement reference. It is not very accurate for a single measurement, but can be very accurate if averaged over a long period of time. This averaging allows us to continually track and update the gyro parameters and, hopefully, to keep the pitch measurement within that 1/2 degree tolerance mentioned above.

And there are other forces that need to be reckoned to meet this requirement. Namely, the centrifugal and tangential forces experienced by the sensors as the head rotates. In an extreme scenario, such as at a Metallica concert, these forces can be as large as a full G. Even in normal cases, they are too large to be ignored. The calibrated gyro measurements can be used to estimate and remove these not-braking accelerations.

Initially, I was optimistic that I could find some existing code that could be adapted to this situation, but no dice.

**Details**

**Initial Gyro Cal**

Here, we estimate the gain and bias parameters of the gyro offline. In this case, we assume the gyro parameters are static and estimate them using the accelerometer measurements (which is already well calibrated). The model for the gyro is linear. That means that the conversion of the integer counts

*c*from the analog to digital converter (ADC) into an actual pitch rate is given by

omega = a

*c*+ b,

where a and b are the unknown parameters we seek. You may be more familiar with the related model:

omega = (c -

*d*)

*f,*

which is the same when

*f = a*and -

*df*=

*b*. But this form has issues with linear estimation because the

*df*term is quatratic. The actual pitch angle is the integral of the pitch rate. Subscripts are used to denote the measurement number: c0 is the first count, pitch0 is the first pitch and so on.

For a small amount of time

*dt*, where small means that omega is not changing significantly over this time period, we can approximate the change in pitch as

pitch1 - pitch0 = (a

*c*0 + b)

*dt,*or

pitch1 = pitch0 + (a

*c*0 + b)

*dt.*

Continuing on,

pitch2 = pitch1 + (a

*c*1 + b)

*dt or,*

pitch2 = pitch0 + (a

*c*0 + b)

*dt +*(a

*c*1 + b)

*dt*or

*,*

pitch2 = pitch0 + a

*dt*(

*c*0 +

*c*1) + b 2

*dt.*

You get the idea:

pitchk = pitch0 + a

*dt*(sum(

*c*i) + b

*dt*k.

If

*N*measurements are taken, we have a system of

*N*equations but only three unknowns (

*a, b*, and theta0), in other words a very over determined system of equations. (We treat theta0 as an unknown, since the actual first measurement is corrupted and we don't want these errors to impact our estimate of

*a*and

*b*.) A little linear algebra makes this situation more manageable.

Let:

Pitch be the column vector of all of the pitch measurements taken from the accelerometer,

*A*be the

*N*x 3 matrix with columns cumsum(C * DT), cumsum(DT), ones,

and

*x*be the 3-vector [

*a, b*, theta0],

C is the vector of gyro ADC counts,

DT is the vector of time deltas (

*dt*s) in practice these may not be all equal,

ones is the vector of all ones.

The product C * DT is taken element wise.

Here cumsum is the cumulative sum of a vector. An example makes this clear:

cumsum([1, 2, 3, 3, 5]) = [1, 3, 6, 9, 14].

With this notation we have the much improved

Pitch =

*Ax.*

This is easily solved using least sqares

*x*= (

*A*^t

*A*)^(-1)

*A*^t Pitch,

where ^t is the matrix transpose of the preceding matrix.

That is it! I collected about 30 seconds worth of data pivoting the unit back and forth in my hand and got a really nice fit. The upper plot shows the pitch measurement for both the accelerometer and the gyro. The lower plot shows the difference between the two measurements. The astute reader might take issue with the large differences up to 10 degrees. This is because the accelerometer also as errors and I can't actually pivot about the gyro as I rotate the unit back and forth with my hands. I will set up a better calibration setup if this turns out to be too bad.

UPDATE 2010-10-22. Nat Dyck, my roommate from college, made me a fancy lego structure to calibrate the gyro. The device allows the SharkFin to spin with the accelerometer at the center of rotation. See road testing.**Doomsday Gyro Cal**

... in which the continual gyro calibration is discussed**.**

So the gyro parameters *a, *and *b*** **need to be updated on a regular basis. We do this by updating our *prior *estimate with new information about the gyro parameters. In this case, since we cannot control the rider's head motion, we must accept the measurements that are provided. The rider my look down a lot to check the chain which would provide a great gain measurement *a*. Or the rider could hold perfectly still and provide a great bias measurement. One thing we to not want to do is to mess up a perfectly good *prior* gain estimate with new data.

We only get insight into the gain measurement when the rider is moving his head. If the rider is holding still we get a crappy gain measurement. Either way we get a gain measurement. It could be a good one, a bad one, or anything in between.

We want to update the prior gain estimate with this new information. Suppose we did something dumb and just averaged our prior gain estimate with the update.

gain_new = (gain_prior + gain_est) / 2.

If gain_est is bad, we just messed up our prior estimate with junk. If gain_est is really really good, we are messing up our gain_est with gain_prior. We really want a weighted average that balances how good we believe gain_est and gain_prior are.

Weighting by the inverse covariance does exactly that.

In other words we need to weight the new estimates by our confidence we have in them for each parameter. A great general purpose weighting scheme is to weight each term in the weighted average by its inverse covariance. When in doubt, this is the goto weighting scheme, optimal in several respects.

Our initial estimate of *x* comes with a covariance of that estimate. Provided we know the covariance of the input data (of Pitch in this case). Since the Pitch vector comes from independent accelerometer measurements, take

cov[Pitch] = sigma^2 *I, **I* being the *N*x*N* identity matrix, and sigma the standard deviation of the individual pitch measurements. Then the covariance of our estimate is

cov(*x*) = sigma^2 (*A*^t *A*)^-1.

This covariance tells us exactly how much we can trust our estimate. If we held very still during the collection period, the gain variance will be very large. The variance comes down the more rate diversity there is over the collection period.

So if we have two estimates for *x* , *x*1 and *x*2, along with the associated covariances cov1 and cov2, we can combine them into a single improved esitmate optimally as*x*_new = (cov1^-1 + cov2^-1)^1 (cov1^-1(*x*1) + cov2^-1(*x*2)).

So we can keep a running estimate in this way by updated our prior estimate with the new data.

The covariance of *x*_new is already computed:

cov(*x*_new) = (cov1^-1 + cov2^-1)^1.

On thing the covariance above does not account for is the amount *x* changes between estimates. To account for this change we add a covariance term to represent it. This is sometimes referred to as plant noise, so I use the symbol cov_plant for it.

In the algorithm that follows, a shortcut has been made for simplicity. Since the Omega measurements are derived from the difference of two pitch measurements, they are not independent. The covariance matrix for Omega is actually tri-diagonal. The increased accuracy however does not justify the increased computational complexity, especially for an algorithm that is intended to run on a micro-controller.**Algorithm Doomsday Cal.**

Inputs:*x*_init -- the initial estimate for *x.*

cov_init -- covariance of *x*_init*K* -- number of measurement to take between each cal update

sigma -- standard deviation of raw pitch measurement from accelometer

cov_plant -- un-modeled covariance

Outputs:*x -- *A running estimate of the gyro parameters a and b.

*x*=

*x*_init

*A*= column(Count, ones(K))

*x*_new = (

*A*^t

*A*)^(-1)

*A*^t Omega

*A*^t

*A*)^-1

*x*= (cov^-1 + cov_new^-1)^-1 (cov^-1(

*x*) + cov_new^-1(

*x*_new))

The gyro gain parameter seems to be very stable. We neither want nor expect this measurement to change much if at all. So in practice, cov_plant and cov_init can be made to prevent large updates to

*a*by making the upper left element of these matrices to be very small implying very accurate prior knowledge of

*a*.

**Radial and Tangential Accelerations**

These sensors are really good. The idea here is to use the gyro measurements to predict the non-braking accelerations and subtract them from the accerometer measurements before the braking estimate is made. It is really exciting to see this Math in Action, literally. We pose a simple circular model for the head movements and take two derivatives to get the acceleration. Comparing the expected results with actual measurements shows both that the model is right and how accurate these sensors are.

The circular model for head movements is:

*p*=

*r*[sin(pitch), cos(pitch)],

where

*r*is the radius of rotation, and

*p*is the sensor position in the [Forward, Up] frame or f-u frame for short (no slight intended). One of the difficulties is keeping track of the sensor x-y frame relative to the f-u frame. That is, I guess, the entire problem.

The velocity vector is the time derivitive of the position vector. Using the chain rule from Calculus I (since pitch is also a function of time with

*d*pitch /

*dt*= omega) the velocity from head motion alone is computed as.

*v*=

*r*[cos(pitch), -sin(pitch)] omega.

Recall that chain rule states that

*f(u(x))' - f'(u(x)) u'(x).*The product rule is

[

*f(x) g(x)*]' = f(x) g'(x) + f'(x) g(x)

Using the chain rule once again with the product rule and letting omegadot be the time rate of change of omega, the acceleration measurement is

*a*= -

*p*omega^2 +

*v*omegadot / omega.

or

a = R + T

where the radial R and tangential T components of the rotation acceleration are given by

R = -

*p*omega^2 and

T =

*v*omegadot / omega

=

*r*[cos(pitch), -sin(pitch)] omegadot

The SharkFin was mounted to a bicycle wheel (see title picture) to confirm no major errors were made in the circular model calculations. A rubber band prevented the wheel from spinning more than 90 degrees. Over the 30 second run, the wheel was spun vigorously back and forth through its range of motion. In the pitcure below, the actual x-y acceleration measurements are transformed into f-u coordinates and compared to these R + T.

The blue line shows the f-u accelerations in Gs predicted from the gyro measurements. The green line shows the accelerometer measurements rotated into the f-u frame. The acceleration due to gravity, [0, 1] in the f-u frame, has been subtracted out as well. This is not a bad fit considering that the two measurements are completely independent.

The next plot shows the accelerations measured in the forward direction. This is the direction we are most concerned with for braking measurements.

The top plot shows the predicted and measured forward accelerations, the middle plot shows the difference between the two (the raw braking measurement). The lower shows the smoothed braking measurement. Ideally, since the motion is strictly circular with no braking involved, we would hope to see zero braking. Because of the large radius and vigorous motion, the errors creep up to .1 Gs. This should be much smaller for an actual helmet mount during non-head-banging activities. The upward trend is due to the gyro measurement drifting away from the true pitch measurement. This is dealt with by using the accelerometer measurements as an absolute, if noisy, reference.

That's it on gyro calibration. If you made it this far, congratulations. I've spared you the details of all of the mistakes and dead ends I have traversed. I'll save the full braking algorithm for another post.

## Tuesday, October 12, 2010

### Its about time: ClockTWO!

Those familiar with Evil Mad Science Peggy2 board will recognize the array architecture right away. It was a huge relief to start with a functional design and our hats are off to the the Evil Scientists! In addition to the array we have added a real time clock, light sensor, buzzer, and I2C interfaces for chaining boards horizontally end-to-end. The small squares on the right are pin compatible breakout boards, dubbed rtcBOB, that are pin compatible with the Chronodot.

Anool did a beautiful job with the layout and routing, painstakingly adding the myriad traces by hand. We ordered 10 boards for our initial run and plan to populate two test boards: one in India and one in the States. If it works like we hope, we will be making it available. If you want to get your hands on one early or have other questions or comments, drop us a line. We'd love to hear from you.

This is an open source hardware project (whatever that means). We will make all of the design files available when we decide on a (commercial friendly) licence.

## Sunday, October 03, 2010

### EMSL Larson Scanner Review

Next, the kit is exactly the right depth. The circuit is simple enough to understood by a novice. It's just a controller, 9 LEDs, 9 current limiting resistors to prevent the LEDs from burning out, and a button. It took her about an hour to complete the kit from start to finish.

Which brings me to my next point: it's pretty freaking cool. When she turned it on for the first time, the LEDs began their smooth back and forth scanning. It is smooth because of the dimmer logic in the pre-programmed controller. It was actually a much cooler effect than I had anticipated. The mode button controls the speed of the scan as well as the brightness.

Because the project is open source, if she decides to, she can crack open the code and modify the functionality. What about a school logo POV? EMSL has provided the breakout for in circuit programming, serial communication, and two ports for customization.

The last salient feature I'd like to mention is the cost. At $13 flat, you can't go wrong.

Maybe it's me, but do I detect a hint of Evil Madness?

## Tuesday, July 27, 2010

### Liquidware Sensors Review

Liquidware, the same folks who brought us the Open Source Hardware Bank have come out with a new line of sensor breakout boards that are worth taking a look at, especially if you are into Arduinos. Several factors distinguish the Liquidware boards from the others that are available.

They are targeted for Arduino. You can, of course, use them with any suitable micro controller out there, but they make it really quick and easy to get the sensors up and running on Arduino. Each sensor has a cheat sheet divided into three sections: "Learn," that describes the basic principles of the sensor; "Connect," that tells you how to connect the sensor to an Arduino, and "Code," that shows a minimal example of how to read data off the sensor. With these cheats, I was able to get the 3-axis accel and the ambiant light sensor up and running within 5 minutes (and to think that I had been putting this off for a month for lack of time).

I think these guys are on the right track here with these sensors. One improvement I might suggest, is to go beyond the basics on the cheat sheet. I think this could be accomplished by shrinking the font a bit and adding a column named "More" or something like that. This column would explain the full funtionality of the device. On the accel for instance, it'd definitely be a plus up to have a table for the G1 and G2 pins that affect the sensitivity of the unit. If done correctly, the new sheet will not frighten beginners, but will be more useful to the pros.

I've used a similar breakout board for the accelerometer (MMA7260QT) from Pololu, which cost about five bucks less. If you go this route, you might need a little more time getting up to speed.

Bottom Line:

If you are a seasoned pro, of course you will not NEED these hints, but even so, they will probably end up saving you some time getting things going.

If your new to electronics, these sensors can increase your chances of success using sophisticated sensors.

## Sunday, June 13, 2010

### The days of the week (or how to pretend like you are a savant)

My younger daughter Elizabeth and I have made a system whose only mental calculation is the addition of three numbers, all of which are less than seven. The sum of the three numbers indicates the day of the week. Sunday = 0, Monday = 1, and so on up to Saturday = 6. To complete the "savant" effect, say things like "Oh, that one is kinda bumpy so it is a Wednesday," or "Friday, it's blue and cold, definitely a Friday." If you decide to give it a go, be sure to try out my days of the week quiz program in the previous post to test yourself.

**All of this math**, takes place in the group of integers modulo 7, which simply means that we only care about the remainder of the number after dividing by 7. In this group, 8 and 1 are "equivalent" since 1 / 7 = 0 remainder 1, and 8 / 7 = 1 remainder 1. They both have the same remainder of one, after dividing by 7 so they are "equivalent" for our purposes. This boils down to the fact the we care ONLY about the day of the week, not how many weeks have passed or will pass between now and then. So we throw out the quotient and keep the remainder. To indicate that the computations are specific to integers modulo 7, "mod 7" is appended to each line. Here are some example calculations in this arithmetic:

0 + 0 = 0 mod 7

1 + 1 = 2 mod 7

4 + 3 = 0 mod 7

6 + 6 = 5 mod 7.

Try a few on your own:

3 + 3 = ? mod 7

5 + 2 = ? mod 7

Sometimes it is convenient to represent 6 as -1 mod 7. Since they share the same remainder after dividing by 7. With this in mind 6 + 6 = -1 + -1 mod 7 = -2 mod 7. Likewise -2 = 5 mod 7 and so on.

**Each day, month, and year**gets assigned an integer modulo 7. For instance in the carefully chosen example above:

So the arithmetic is simple. The tricky part is memorizing the number assignments for the months and years. Let's make it simple by only considering dates in the current year (2010) and focus on the months and day assignments. The year 2010 gets assigned a 4 (we will talk about why later).

**The day assignments**are the easiest: just take the day number modulo 7. The 15th of the month gets a 1 for instance since 15 = 1 mod 7.

**The month assignments,**in row order are:

Jan:0 Feb:3 Mar:3

Apr:6 May:1 Jun:4

Jul:6 Aug:2 Sep:5

Oct:0 Nov:3 Dec:5

or leaving off the month names for compactness:

0 3 3

6 1 4

6 2 4

0 3 5

In this system, this block of 12 numbers must be memorized backwards and forwards, by rows and by columns, inside, outside and upside-down. Some months are easier for me to remember than others:

January is a 0 (it starts everything off)

March is a 3 (third month of the year)

May is a 1 (May Day falls on May 1)

October is a 0 (The big O in October looks like a zero).

The others just need to be memorized. It's not actually that bad, but if you think of a good mnemonic, let me know.

A brief note on how the month assignments are made. January gets assigned a 0 to start things off. This is somewhat an arbitrary choice, but if you change it, you will also have to change the year assignments. Since January has 31 days and 31 = 3 mod 7, the first of Feb is three days of the week offset from the first of January, thus February gets assigned a 3. February has 28 days (exactly 4 weeks) most years so March 1st will fall on the same day as February 1st most years. Thus, we assign a 3 to March. March has 31 days which makes April 3 days offset from March (which was already 3 days offset from January 1st) , so April gets assigned a 6 (3 + 3 = 6 mod 7). Carry this process forward to compute the assignments for the other months.

With this in hand, you can compute any day of the week for the year 2010:

Oct 14, 2010 = > 0 + 0 + 4 = 4 mod 7, a Thursday

Mar 10, 2010 = > 3 + 3 + 4 = 3 mod 7, a Wednesday

July 4, 2010 = > 6 + 4 + 4 = 0 mod 7, a Sunday

...

**Now to tackle the year assignments.**Be sure to get really fast for the current year before you go any further.

For reasons that might become clear later, the year assignment is the day of the week that March 4th falls on. March 4, 2010, happens to be a Thursday, so 2010 is a 4. Using a calendar we get the following assignments for some nearby years:

**2007 = > 0**

2008 = > 2

2009 = > 3

2010 = > 4

2011 = > 5

**2012 = > 0**

2013 = > 1

2014 = > 2

Observe that the years go up by one whenever the year is NOT a leap year. For a leap year the assignments are 2 larger than the previous year. This makes since since 365 = 1 mod 7 for a normal year, and 366 = 2 mod 7 for a leap year. Zero years are thus convenient milestones to anchor the assignments for neighboring years. Elizabeth and I have dubbed a zero assigned year, like 2007, as a

**zear**.

Every 28 years a zear falls on a leap year like 2012. These special years get a special name in this system. When a zear is also a leap year, it is refferred to as a le-zear pronounced "le" as in French with great flourish and accent on the second syllable: le-

**Zear!**

Leap years require additional caution (Elizabeth always gets me on this!). If the date of interest is is in January or February of a leap year, subtract 1 from the count. Example:

January 25, 2012 = > 0 + 4 + 0 = 4 mod 7 - 1 = 3 Mod 7, a Wednesday.

**Additional hints:**

Within 100 years of 2000, the year assignments repeat every 28 years so 1970 gets the same assignment as 1998. This pattern is broken by the following fact.

1900 is NOT a leap year. Every one hundred years we skip a leap year, unless the year is divisible by 400.

## Friday, May 28, 2010

### Days of the week.

## Monday, May 24, 2010

### ADXL345 Arduino Driver II

## Sunday, May 23, 2010

### Arduino: undefined reference to `loop'

This is the example that got me. The Arduino project .pde file is a test of an accelerometer library (Adxl345.cpp, .h). Here is what the directory listing looks like.

.../sketchbook/Adxl345/Adxl345.pde

.../sketchbook/Adxl345/Adxl345.cpp

.../sketchbook/Adxl345/Adxl345.h

This yeilds the cryptic error

undefined reference to `loop'

or sometimes

undefined reference to `setup'

or both. The fix is to rename the Arduino project as anything other than "Adxl345". Using "Save As" in arduino should do the trick. This is what the listing looks like that works:

**_test**/Adxl345

**_test**.pde

**_test**/Adxl345.cpp

**_test**/Adxl345.h.

## Friday, May 14, 2010

### ADXL345 Arduino Driver

A simple test script is located in the examples directory.

## Wednesday, May 12, 2010

### WORDUINO Instructions

## Saturday, May 08, 2010

### SharkFin Sensor Swap -- SFSS

Along comes the 9 degree of freedom Razor IMU from SparkFun. This $125 bad boy has 3 axes of accel, 3 of gyro and 3 magnetometer, overkill for sure. I got this for experimentation and found out that it fit beautifully on Fin. The holes even lined up. This amazing foresight by Anool, enabled the sensor swap.

The 9 dof razor has a ATMEGA328 on board already. I reprogrammed the MEGA on the SharkFin base to be a digital slave dummy. It just listens on the serial port for 3 byte messages which it assigns to the digital ports: PORTB, PORTC, and PORTD. This simple interface could be expanded to also read digital inputs from the slave.

The accel datasheet indicates a selectable bandwidth. It is unclear on exactly how this is being accomplished, but if it is effective, this will relieve the huge burden on the processor of low-pass filtering the accel data.

The magnetometer offers the possibility of complete head orientation tracking. It is still unclear exactly how to take advantage of this given that there is no true velocity measurement. Ideas are welcome!

### Anool receives Alden's minature WordClock.

## Saturday, May 01, 2010

### WordClock Delivered

I dropped off a word clock to Alden (creator of the miniature word clock). I had mistakenly come to the conclusion that Alden had a laser cutter. I will forward the super cool golden face plates when they arrive from Anool. You can see the word clock on the left of the work bench.

While I was there he showed me around his beautiful shop. This is a dream shop, well lit and spacious, with enough components on hand to invent the future (which is what he is doing!).

Below, Alden is checking the performance of a stepper driver he has been working on. The steppers must have gotten out of hand in the second photo as the whole room seems to be spinning.

## Sunday, April 18, 2010

### Yet Another WordClock

## Friday, April 16, 2010

### Laser Cut Face and Baffels

He is testing a diffuser over "O'CLOCK", that is how the final product will look.

## Monday, April 12, 2010

### WordClock boards have arrived

The WordClock board from Anool arrived!

The clock consists of three boards: Main board which houses the ICs, the LED board and the face (pictures to come)

Everything seems to be working except the reset from the FTDI interface. hmmm.

Yet another blinking light, and it is a miracle every time!

## Sunday, March 28, 2010

### SharkFin-- The first wireless helmet mounted brake light!

Hurray!

## Wednesday, February 24, 2010

### HACDC Lightning Talk

## Saturday, February 20, 2010

### IT WORKS!!!!

## Friday, February 12, 2010

### Strap-On Shark Fin Boards!

## Thursday, February 11, 2010

### 1^2 + 2^2 + 3^2 + 4^2 + 5^2 + ... + n^2

*S*is

*n*(

*n*+1)(2

*n*+1)/6. And proofs abound. Although this relationship is not difficult to prove by mathematical induction, it is not intuitively satisfying. This visual proof is very clear and easy to understand.

We ended up with an expression that contained in part, the sum 1 + 4 + 9 + 16 + 25 + 36 + 49 + 64. It was clear that if we had used instead

*n*coins each of width 1/

*n*, to approximate the volumn, part of

*that*expression would intail the sum

*Sn*= 1 + 4 + 9 + 25 + ... +

*n*^2. To no avail, I looked around for a simple way to demonstrate the well known relationship:

*Sn*=

*n*(

*n*+1)(2

*n*+1)/6.

*Sn*as the volume of the pyramid of 1 x 1 x 1 cubes with one cube on the top layer, 4 on the next, 9 on the next and so on up to

*n*x

*n*cubes on the bottom layer as seen in the figure above.

*Sn =*

*n*(*n*+1)(2*n*+1)/6, we see that*S**n**is one sixth the volume of a box with dimensions**n*x (*n*+ 1)*x*(2*n*+ 1). So it is at least conceivable that six of these pyramids could be packed into that rectangular volume. Elizabeth and I glued 30 wooden cubes into 6 two-layer pyramids (1 x 1 + 2 x 2) as shownand without too much effort arranged them into a 2 x 3 x 5 rectangular volume.

*n*. Here are some screen shots of a Python simulation using

*n*=4 demonstrating the configureation.

Now fast forward a few days. Snowmaggeddon has snowed me OUT of Reston, VA, and I'm stuck in LA on a rainy Saturday. Amy (lovely wife) scouts out a meeting of the LA Microcontrollers Club from the Make Blog. The once-a-month meeting was scheduled to start in only three hours. A quick peak at the map revealed Topanga, CA, to be just up the mountain North of Santa Montica, about a forty-five minute drive from my hotel. Sweet.

It was fun getting to know Jack, the founder of the LA Mircrocontroller Club and freelance maker (see see buffingtonfx.com) and Nick, a freelance Hollywood tech.

Nick brought his Arduino-based movie prop clock that stays on whatever time you set it and won't flicker when filmed. Jacked showed off his awesome shop, with a DIY CNC router, and shared his recent experience with the Propeller development board.