• # Rebuilt Engine

Fri 15 March 2013 - 11:33:09 CDT

The marathon coding sessions are done; 35 productive hours over three days. I deleted a bunch of code and made this blog more maintainable.

Writing the original blog engine in Rails was a great case study, but at the end of the day, there are plenty of things out there that handle blogging and have much more mature editors than my initial crack at it.

In short, inspired by Thoughtbot’s Tools of the Trade and Seth Godin’s bullet point about leveraging cheap off the shelf software, I dropped the Rails ActiveRecord model for the blog and instead hooked into Tumblr’s API. (Tying into an external API was another good exercise for upcoming projects.)

The end result is that you should be getting more posts from me and more often. And this also gives me solid base from which to launch my podcast.

Stay tuned.

• # Dietary Intake

Mon 11 March 2013 - 14:10:00 CDT

I was reviewing customer requirements on a recent project, and we came across something unintentionally comical. There was a requirement for illumination intensity which is given as power per unit area, in this case microwatts per square centimeter (uW/cm^2). The problem was that the m was missing leaving uW/c^2.

6 ounces of cake over 10 minutes is roughly 0.28g/s.

Now c is not a unit, but in the context of light, it represents the speed of light with units of meters per second. Just for fun, I plugged this into Wolfram Alpha as “500uW/c^2”. This reduced to having units of kilograms per second which the tool interpreted as “recommended dietary intake”!

This instance was an obvious typo, but it does highlight the need to be careful when authoring and reviewing requirements. Missing a digit, for example, could have far-reaching consequences for your project. And completely wrong units can cause your Mars probe to crash. Better to catch these things early.

And while we‘re on the subject, what do you use for requirements management? I’m guessing Word/Excel is a popular answer. Leave a comment below. This is a topic I will be covering in future posts.

• # User Error

Mon 04 March 2013 - 12:48:00 CST

I’ve been keeping this link around for a while because the first one on the list actually happened to me in the Detroit airport. Well, something very similar. I had a flight leaving soon, wanted coffee, but can’t drink it—especially quickly—when it’s too hot. So I asked the barista to put some ice in the cup to which she replied, “Do you want the ice at the bottom or the top?”

I had no idea how to respond to this except to think to myself, “If you can keep the ice at the bottom, that would be a neat trick.”

At any rate, it is a short, interesting article that reveals a bit about what all scientists, engineers, and product designers are up against sometimes. Remember these when you are:

• planning user research.
• building requirements for your new product.

And contact us if you need another set of eyes on your requirements, need people to help with your STEM initiative, or if you have an idea for something you would like to learn from this blog.

• # Shoreline Waves

Tue 12 February 2013 - 19:05:00 CST

In a previous post I mentioned that an optical plane wave—or any plane wave for that matter—when viewed in the frequency domain has a spatial frequency that depends on its arrival angle. Oftentimes, the data you see in the frequency domain is referred to as a spectrum, and plane waves arriving from different angles form an Angular Plane Wave Spectrum.

Waves near Jacksonville Beach, FL.

Looking at unit conversion, going from the time domain to its corresponding frequency domain converts from seconds to 1/seconds (or cycles per second or Hertz). Space, millimeters, goes to 1/mm (or sometimes line pairs per mm). But how do we go from an angle in radians to 1/mm?

First, consider a shoreline with waves coming in. The waves are comprised of a series of peaks and valleys with some spacing—the wave period—and they are traveling along a line that intersects the shoreline at some angle. If you were to freeze time and walk down the shoreline, you’ll also see peaks and valleys, and the spacing here is what defines the spatial frequency of the wave in the plane of the shoreline. (In optical terms, the “shoreline” could be any plane of interest in the system: an aperture, a lens, a sensor, etc.)

A traveling wave. Note how when the wave is sliced at an angle, the cross section is also a sine wave but with a lower frequency.

The simplest case, of course, contradicts what I just said. If the waves are coming in directly at the shore, as you walk along, the amplitude does not have peaks and valleys. It is constant, or has zero frequency (or is DC if you are an electrical engineer). As the angle of incidence increases, peaks and valleys appear, but they are spaced very far apart from each other. That is they have a low frequency, and the frequency increases as the angle increases. (In the limit, the angle is 90 degrees, the wave is traveling parallel to the shore, and the apparent frequency is equal to the wave frequency.)

Peaks and valleys of a plane wave crossing the “shore” at an angle. The double arrow denotes the period of the traveling wave. The spacing between two peaks along the shore gives the wave period—one over the frequency—in that plane.

Finally, a little trigonometry will give us the frequency of the wave in the angular plane wave spectrum as a function of its angle and period. Look at the same figure with a superimposed triangle. The wave (with period lambda) arrives at an angle, theta, relative to the dashed line which is perpendicular to the plane of interest (i.e. theta is relative to the plane normal). The spacing between peaks in the plane of interest is the hypotenuse of the triangle, and the length of this is the inverse of the spatial frequency, f, in the plane.

The same figure with a superimposed triangle. (Get that trig identity table out.)

So f is given by:

$$f=\frac{\sin(\theta)}{\lambda}$$

This has units of 1/length which is expected for spatial frequency, and the sine function takes care of the angle units.

Thu 07 February 2013 - 15:00:00 CST

Ok, here’s an easy one. When does 17+17=20?

I was looking at basic WiFi power limits just now and one of the tables caught me off guard for a second until I looked at the units. (Always check units.) One of the tables indicates that a system can have two antennas with output power from each of 17 for a total of 20. How?

The catch is that the power figures are in dBm which is a logarithmic scale so addition isn’t just addition anymore. And units of dBm give the output power in decibels (dB) relative to 1 milliwatt (which is where the “m” in dBm comes from).

So take your output power, say 5mW. Relative to 1mW, this is 5 times larger, or about a 7dB increase:

$$10\cdot \log_{10}\left(\frac{5\text{mW}}{1\text{mW}}\right) \approx 7\text{dBm}$$

Likewise, 1mW is 0dBm; there is no increase or decrease from the 1mW reference.

(Also, if you’ve seen the dB calculation with 20log instead of 10log, that is for amplitude, not power. Power is proportional to amplitude squared so you lose a factor of two after the log. But I digress…)

Working backwards, 17dBm is equivalent to about 50mW. Twice this is 100mW which is equivalent to 20dBm. 17+17=20.