ClockTHREE Matrix Complete!

ClockTHREE is Kickstarter "Project of the Day!"

Suck on that, cool ipod watch thingy!

Mini Word Clock Available Online!

Remember Alden's tiny word clock?  Well he and Riley have taken that project to the next level by offering 100 of these clocks online for $59!  The production version looks great with a clear back panel. Besides its handsome appearance, this is the most affordable word clock available.  Congrats to Alden and Riley!

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

Kickstarter projected launched!

Alright all you silent readers, now I need your help.
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!

Square Pegs

NNNnnoooooooooo!

How do you fit a square peg into a round hole?

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?

ClockZWEI

I wanted to see how difficult it would be to add another language.  German!  Now for some cool graphical effects.  Not too difficult, but we need a real German to tweak it for us, volunteers?  Code available here.

And now something new from the Overkill Department ...

This clock reads the NMEA message from the GPS and sends it over to the 7-segment serial display.

This is just a simple application to experiment with GPS and serial display. The stack-up consists of a GPS module, a GPS shield, a double-tall ExtenderShield, and 7-segment serial display. In the photo, the flash washed out the LEDs, but this display is really bright (with digital dimmer options, too). The setup worked better than I expected. The GPS even got a location fix from my basement. This was one of the few projects where everything worked pretty much the first time, and only took about an hour.

... I'm thinking this would probably not be a good project to ship over seas right about now.

ClockTWO Simulator

The ClockTWO boards should be completed in Mumbai today. Then it will take another couple of weeks to get a few sent here. In the meantime I've started working on the code.

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

f -- forward five minutes

F -- backward five minutes

h -- forward one hour

H -- backward one hour

The I, M, and D buttons emulate the hardware buttons. I moves forward one minute, D move back one minute, and M changes the color.

Please download, test, and provide feedback.

First Road Test

The pitch tracking worked well. It was obvious that some yaw and roll tracking will be necessary. The lights come on when the rider looks around. Also sensitivity could be improved.

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.

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 = (ac0 + b) dt, or

pitch1 = pitch0 + (ac0 + b) dt.

Continuing on,
pitch2 = pitch1 + (ac1 + b) dt or,
pitch2 = pitch0 + (ac0 + b) dt + (ac1 + b) dt or,
pitch2 = pitch0 + a dt(c0 + c1) + b 2 dt.


You get the idea:
pitchk = pitch0 + a dt (sum(ci) + 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 NxN 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 , x1 and x2, 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(x1) + cov2^-1(x2)).
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.

#initialize

last_theta, last_time = measure theta, time

x = x_init

cov = cov_init

while 1: # loop forever (or until doomsday)

Omega = []

Count = []

for k in [0..K-1]:

measure theta, c, time

Omega.append((theta - last_theta) / (time - last_time))

Count.append(c)

last_theta = theta

last_time = time

A = column(Count, ones(K))

x_new = (A^t A)^(-1) A^t Omega

cov_new = sigma^2 (A^t A)^-1

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

cov = (cov^-1 + cov_new^-1)^-1 + cov_plant

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

Its about time: ClockTWO!

I know you've been asking yourself, why is there no large open-source-hardware RGB LED array available? Anool and I wondered the same thing. You may have seen our earlier clock, the Worduino, based on Doug Jackson's ever popular Word Clock. This time, we decided to design a general-purpose Arduino based RGB array. The hefty 12 x 9 inch board supports up to 160 individually addressable RGB LEDs and an additional 32 mono LEDs which will easily accommodate a word clock. Our improved faceplate allows you to program reminders to hydrate with your favorite beverage. Looks like its "beer thirty" again. But, if you put a map transparency in front of it, you got the makings of a sunclock. Or maybe you just need some colorful scrolling text.

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.

EMSL Larson Scanner Review

UPDATE October 2010. Safety by Prada!

My 14-year-old daughter put together the Larson Scanner Kit offered by the Evil Mad Science Laboratories (EMSL). We have put together quite a few soldering kits around here and this one is, simply put, the best "learn-to-solder" kit I've ever come across. There are several reasons for this. First off, the instructions are great. Not only are they clear, they leave no uncertainty as to what you need to do at each step, but they are in the form of a comic book, the perfect medium for this kit. This keeps the project light and fun.

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?

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.

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

Being able to tell what day of the week a date like October 28, 2012, will fall on seems like an impressive feet of computation. It is actually quite simple if you can memorize a few numbers.

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:

October = > 0

28 = > 0

2012 = > 0,

so October 28, 2012 falls on a Sunday (0 + 0 + 0 = 0 mod 7).

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.

Days of the week.

I while back I wrote a day-of-the-week quiz program.  Now for the life of me I can't find it.  I re-wrote it.  Here it is.  Get good at it and amaze your friends.

ADXL345 Arduino Driver II

I found a much more complete driver for this accelerometer thanks to Kevin Stevenard.  I updated the code and renamed a few things.  The changes were, unfortunately, not backward compatible.  I've reposted the modified code here.

Thanks Kevin!

Arduino: undefined reference to `loop'

Ok, since this is the second time this has baffled me, I am making a note to myself. It turns out you cannot have a library with the same name as the pde file.

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:

.../sketchbook/Adxl345_test/Adxl345_test.pde

.../sketchbook/Adxl345_test/Adxl345.cpp

.../sketchbook/Adxl345_test/Adxl345.h.

ADXL345 Arduino Driver

I wrote a simple driver for the ADXL345 accelerometer on the Razor board.  The code provides read/write access to the registers on the device and allows you to change the bandwidth of the internal low pass filter.  This little chip has an in-depth interface with stream buffering, fall detection, bump detection, double click detection besides autonomous low pass filtering.  I have only scratched the surface here.

A simple test script is located in the examples directory.

WORDUINO Instructions

Anool has prepared a beautiful set of instructions for our WordClock. Unfortunately, there are only 6 copies of the boards so consider yourself lucky if you got a set. If anyone expresses an interest, we may make more of the next edition of WORDUINO. Please let us know if you are interested.

The flexible faceplate lettering has been laser etched.

This picture shows the laser cut baffles to isolate the light to individual words.

SharkFin Sensor Swap -- SFSS

I take it back. On the original SharkFin, the analog circuitry was causing a small error in both the gyro and accel measurements. We've since corrected the design, but we didn't want to lay money down on a new set of boards until the concept was proven.

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.

After over a month, Anool finally received the package containing Alden's miniature WordClock.  Here are some photos of his careful vivisection.

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.

Yet Another WordClock

First pass I tried to save room by soldering the power cord directly into the board. It turned out there was plenty of space on the back side of the board as seen below.

The boards are held in place with surplus proto-board. A slit has been cut in the corner of the the enclosure from the outside of the box to accept the holder. This keeps the board stable in both forward and backward directions.

Still missing the baffels, but the result is easily readable.

Laser Cut Face and Baffels

Unhappy with how the clock face turned out, Anool, redesigned them to be laser cut and the results speak for themselves!

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

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!

SharkFin-- The first wireless helmet mounted brake light!

I've been consumed for the past month with the SharkFin. The gyro drift and analog glitches nearly did me in. I am reporting in the wee hours of the morning today, that the first version is functional! May still need to play with the thresholds after road testing but, (famous last words) I feel confident that there are no more major hurdles! More pics and vids to come.


Hurray!

HACDC Lightning Talk

I made it through a few of the charts of my Lightning Talk before my 5 minutes was up at HAC DC last night. It was a great evening of amazing presentations and after all the presentations were done, Alden Hart gave me a beautiful and tiny word clock. I'll put the link to the video here when it's available.

IT WORKS!!!!

The boards arrived FedEx this morning from Mumbai. I got right to work on the first prototype when I got home. It friggin worked the first try! The boards exceeded all of my expectations! Lights work. Sensors work. Serial port works. Unbelievable.
Three cheers for Anool! Three cheers for SharkFin!

Strap-On Shark Fin Boards!

 

Anool has completed the machining of the Strap-On Shark Fin boards and they came out beautifully.  Half of them will be arriving from India soon!

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

It is well know that the sum of the squares of integers S is n(n+1)(2n+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.

Elizabeth, my 10-year-old daughter, wanted to figure out the volume of a sphere. Making approximations using 16 equal thickness coin shaped cylinders as seen below.

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)(2n+1)/6.

Imagine the sum 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.

From the expression Sn =n(n+1)(2n+1)/6, we see that Sn is one sixth the volume of a box with dimensions n x (n + 1) x (2n + 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 shown

and without too much effort arranged them into a 2 x 3 x 5 rectangular volume.

The configuration is general, in that it can be scaled up to any positive integer 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.

Luckily, I got an early start because the direct route was closed because of the Niagra of mudslides. Rerouting was tricky with my gps-phone rebooting every two minutes. I finally arrived at this beautiful location at the end of a mile-long jeep trail.  The Ford Focus I was driving had trouble negotiating the rutted climb, but the view was worth it.

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.

Getting to the point, Jack kindly offered to route out the pyramid shapes with his CNC router. Literally, an hour later, Jack had produced three perfect five-layer pyramids. He would have made all six, but I was already late for another appointment. Had I known that Jack was planning to give the pyramids to me, I definitely would have waited for the top half of the retangular volume!

Thanks Jack!