Depth of Focus


Without diffraction and atmospheric turbulence, ideal telescopes would focus stars to points. However, there would also be a single focal point, plane or surface and everywhere else would be out of focus. Back in the real world, where diffraction, atmospheric turbulence and telescope flaws exist, stars are not imaged as points, but rather as Airy disks or seeing disks that are larger. This leads to a range where focus can be obtained. This range is called depth of focus and is the topic of this document.

We’ll first describe depth of focus in more detail. Afterwards, we’ll derive it mathematically and present an approximation and a simplification based on ideal seeing. We’ll then present data for various telescope configurations and discuss challenges with focusing fast optical systems.

Depth of Focus

Today’s telescopes are generally diffraction limited. This means that defects in design and construction are not the limiting factors in focusing a star to a point. The aperture of a telescope limits its ability to focus a star to a disk smaller than an Airy disk. Due to atmospheric conditions this limit is rarely achieved. Good seeing conditions result in disks as small as 2 arc-seconds (2″) in diameter.

The above figure depicts light from a star entering a reflector telescope from the left and being brought to a focus at the point labelled Focus. As this cone of light converges towards focus, its cross-sectional diameter decreases until focus is reached. Beyond focus its diameter again increases. When the cross-sectional diameter is as small as the Airy disk, or the minimum size disk obtainable due to seeing conditions, there is nothing gained by it being brought closer to the point of focus. The vertical red lines indicate the region within which the image is as small as conditions permit. The length of this region is the depth of focus.


The angle, \theta_{cone}, formed by the sides of the cone at the focus, is

    \[ \theta_{cone} = 2 \sin^{-1}(\frac{\text{Aperture}}{2 \times \text{Focal Length}}) \]

where \theta_{cone} is measured in degrees and the Aperture and Focal Length of the system are measured in meters. Recall that the focal length divided by the aperture of a system is its f-number. Thus,

    \[ \theta_{cone} = 2 \sin^{-1}(\frac{1}{2 \times \text{f-number}}) \]

As previously mentioned, the cross-sectional diameter of the cone decreases as the focus is approached. We are interested in the distance from the focus to where the cross-sectional diameter of the cone is equal to the diameter of the seeing disk. This is illustrated in the following figure.The distance from the seeing disk on the right to the focus on the left is,

    \[ \frac{1}{2}F_{depth} = \frac{\frac{1}{2}D_{size}}{\tan \frac{\theta_{cone}}{2}} \]


    \[ F_{depth} = \frac{D_{size}}{\tan \frac{\theta_{cone}}{2}} \]

where F_{depth} is the depth of focus in meters, D_{size} is the size of the seeing disk in meters and \theta_{cone} is the angle of the converging sides of the light cone at the focus, in degrees.

The size of a seeing disk is described by the following equation.

    \[ D_{size} = \frac{2\pi}{360} \theta_{disk} \times \text{Focal Length} \]

where D_{size} is the seeing disk size in meters, \theta_{disk} is the angular size of the seeing disk in degrees, and Focal Length is measured in meters.

Through substitution we obtain the result,

    \[ F_{depth} = \frac{\frac{2\pi}{360} \theta_{disk} \times \text{Focal Length}}{\tan (\sin^{-1}(\frac{1}{2 \times \text{f-number}}))} \]


    \[ F_{depth} = \frac{\frac{2\pi}{360} \theta_{disk} \times \text{Focal Length}}{\frac{(\frac{1}{2 \times \text{f-number}})}{\sqrt{1-(\frac{1}{2 \times \text{f-number}})^2}}} \]


By noticing that the ratio in the denominator of the above equation is approximately equal to \frac{1}{2 \times \text{f-number}} the above equation can be simplified.

    \[ F_{depth} = \frac{\frac{2\pi}{360} \theta_{disk} \times \text{Focal Length}}{\frac{1}{2 \times \text{f-number}}} \]

In addition, this result can be simplified and the units of \theta_{disk} can be converted to arc-seconds, to yield,

    \[ F_{depth} = \frac{4\pi}{360} \frac{\theta_{disk}}{3600} \times \frac{(\text{Focal Length})^2}{\text{Aperture}} \]

where F_{depth} is the depth of focus in meters, \theta_{disk} is the angular size of the seeing disk in arc-seconds, Focal Length is measured in meters and f-number is the numerical f-number of the system.

Ideal Seeing

Ideally a telescope with an aperture d can focus a star to a seeing disk with an angular diameter of an Airy disk. An approximation for the radius of an Airy disk is given by,

    \[ \theta = 1.22\times\frac{\lambda}{d} \]

where \theta is the radius of the Airy disk in radians, \lambda is the wavelength of light in meters and d is the diameter of the mirror or lens in meters. Manipulating this equation to yield a disk diameter in arc-seconds yields,

    \[ \theta = \frac{360}{2\pi} \times 3600 \times 2.44\times\frac{\lambda}{d} \]

where \theta is now in arc-seconds and represents the diameter of the Airy disk.

If we adjust \theta_{disk} to be equal to \theta, derived above for the given Aperture d, we obtain,

    \[ F_{depth} = \frac{4\pi}{360} \frac{\frac{360}{2\pi} \times 3600 \times 2.44\times\frac{\lambda}{d}}{3600} \times \frac{(\text{Focal Length})^2}{\text{Aperture}} \]

This simplifies quickly to,

    \[ F_{depth} = 2 \times 2.44\times\frac{\lambda}{d} \times \frac{(\text{Focal Length})^2}{\text{Aperture}} \]

Recalling that, for this ideal case, we constrained d and Aperture to be equal, this simplifies to,

    \[ F_{depth} = 4.88 \times \lambda \times \text{f-number}^2 \]

where \lambda is the wavelength of light in meters being observed or imaged and f-number is the numerical f-number of the system. F_{depth} can be adjusted for degraded seeing by multiplying it by the ratio of the width of the seeing disk to the width of the Airy disk for the chosen aperture.


The following table contains depth of focus values in microns for ideal seeing at various f-numbers using the derived equation, the approximate equation and the final equation based on ideal seeing. We’ll assume an aperture of 280mm as two of the three equations require focal length and aperture as parameters. The Airy disk diameter for an aperture of 280mm is 0.97″.


There are two important conclusions that can be drawn from the data in the above table. First, all three of the derived equations yield quite similar results. Second, the fact that the depth of focus is proportional to the square of the f-number is significant. This means that at f/10 the depth of focus is approximately 263 microns while at f/2 it is only about 10.5 microns. It is important to remember that these figures are for seeing disks with a diameter equal to the diameter of the Airy disk. In great seeing conditions where the seeing disk might be 2″, these figures would increase to approximately 543 microns and 21 microns respectively.

For fast telescopes, such as those operating at f/2, the depth of focus is very narrow. These tight tolerances may make focusing these systems a challenge.


In this post we described depth of focus and derived it mathematically. We then presented an approximation and a model that assumes ideal seeing. The ideal seeing model is routinely used by others and yields good results. Finally, we presented depth of focus figures for various f-numbers and determined that focusing fast optical systems may be problematic.


Field Rotation and Alt-Azimuth Mounted Telescopes


Telescopes can be mounted in a variety of ways. Two common telescope mounts are the altitude-azimuth, or alt-azimuth, and the equatorial mount. The alt-azimuth mount is easier to construct than an equatorial mount, but requires motion on both axes to accurately track celestial objects as they move across the night sky. Astrophotography using an alt-azimuth mounted camera system suffers from field rotation, whereas properly aligned equatorial mounted systems do not. The intention of this document is to describe field rotation and determine its impact on astrophotography. In addition, we’ll determine where astrophotography with a CPC 1100 GPS XLT system used in its f/2 configuration can be successful using its alt-azimuth mount.

Telescope Mounts

As previously mentioned, the two most common telescope mounts are the alt-azimuth and equatorial mounts. A system utilizing an alt-azimuth mount can benefit from the features of the equatorial mount with the addition of a wedge. This section describes these three mounts and briefly discusses their pros and cons.

Alt-Azimuth Mount

An alt-azimuth mount often consists of a pair of forks that stand vertically. These forks rotate around the vertical or azimuth axis. The telescope is attached to the forks and can pivot on the horizontal or altitude axis. This system is obviously quite simple to construct and operate, but to track celestial objects, in their apparent circular paths across the sky, requires nearly constant adjustment of both axes. The introduction of microprocessor-based control systems has made this tracking viable.

Equatorial Mount

An equatorial mount has two perpendicular axes. The first axis is aligned with the earth’s axis of rotation, right ascension. The second is perpendicular to the first, declination. The telescope is attached to the second axis. To track a celestial object using this mount, the telescope is pointed to the desired object, found at a specific right ascension and declination, and then a constant sidereal clock drives the right ascension axis to compensate for the earth’s rotation.

Open Fork Mount

An alt-azimuth fork mount can be configured to benefit from the features of an equatorial mount by aligning the azimuth axis with the earth’s axis of rotation, providing motion in right ascension. The telescope can then swing between the forks in declination.  The device used to align the fork’s axis with that of the earth is commonly referred to as a wedge. With the addition of a wedge, the alt-azimuth mount must only be driven in right ascension to track celestial objects.

Field Rotation

As a constellation rises, crosses the sky on an apparent circular arc and sets, you’ve likely noticed that it appears to rotate. For example, as the constellation Orion rises in the east it may appear to be leaning slightly to the left, at its highest altitude it may be upright and as it sets it appears to be leaning to the right. This is illustrated below.Let’s continue using the Orion constellation as our example. If you’re imaging with a system on an equatorial mount, the telescope and associated camera rotate in right ascension, as illustrated below. The gray rectangles in the figure represent the field of view of the imaging system. The camera retains its relative orientation to the celestial body being photographed. If the equatorial mount is accurately aligned with the earth’s axis, no field rotation occurs.

Unlike the previous example, if you’re imaging with a telescope on an alt-azimuth mount you will experience field rotation.  In the following illustration, the gray rectangles again represent the field of view of the imaging system. Over time the imaging system remains centered on the middle star of Orion’s belt, but the camera remains level with the horizon due to the orientation of the mount’s two axes of rotation.

Notice in the above figure that Orion appears to rotate in the field of view as time passes. If the gray boxes represent distinct times within a long exposure, the stars in the constellation would appear as arcs rotating in a clockwise direction around the center of the frame, in this case, the middle star of Orion’s belt. This is what is meant by field rotation and it is generally undesirable.

It should be clear that equatorially mounted systems do not suffer from field rotation issues. However, this is only true if they are well aligned with the earth’s axis of rotation. While alt-azimuth mounted systems typically suffer from field rotation, solutions have been developed that rotate the imaging system to counter the field rotation. While some of these solutions have been available to amateur observers in the past, it doesn’t appear that any commercial solutions are currently available. In addition, software can be used during post processing of images to remove some of the artifacts introduced by field rotation.

The above examples illustrate the basic issues related to field rotation and astrophotography. However, field rotation is more complex than first meets the eye. In the northern hemisphere when looking south, like in our example above, the field rotation is in a clockwise direction. Looking north we observe counterclockwise field rotation, and this complexity is just the beginning. In the next section, we’ll investigate the math describing field rotation and present associated graphs.

The Math of Field Rotation

As eluded to in the previous section, field rotation is more complex than our simple examples lead one to believe. It would be easy to believe that the rate of rotation is constant or that rotation continues in the same direction as observed bodies fall below the horizon, neither are true. In this section, we’ll introduce the math behind field rotation and illustrate graphically what this means. The rate of field rotation is defined as,

    \[ \omega_f = \omega_{earth} \times \cos latitude_{observer} \times \frac{\cos azimuth}{\cos altitude}  \]

where \omega_f is the angular velocity of the field rotation in degrees per second, \omega_{earth} is the angular velocity of the earth’s rotation in degrees per second, latitude_{observer} is the latitude where the observations are made, and azimuth and altitude describe the coordinates of the celestial body of interest, at the time of observation, in degrees.

There are a few interesting observations regarding this equation. First, if the observer is at either pole, the \cos latitude_{observer} will be zero resulting in \omega_f being zero. This is easily visualized if you imagine standing precisely on either pole and observing the movement of the stars. They will move around you with no change in altitude. This path is easily tracked by rotating around the azimuth axis of an alt-azimuth mount. Second, the field rotation is maximal at the equator where \cos latitude_{observer} is equal to 1. However, as illustrated in the following figure, the increase in field rotation from latitude 40° north to the equator, for any given azimuth and altitude, is only about 30%. In this figure the horizontal axis is latitude in degrees, where negative values represent latitudes in the souther hemisphere. The vertical axis is the value of \cos latitude_{observer}.

Second, if the \cos altitude is zero we have a divide by zero issue. This occurs at an altitude of 90°, the zenith, where field rotation is infinite and cannot be tracked by an alt-azimuth mounted telescope.

With regard to the field rotation equation, there are four variables of interest, namely \omega_f, azimuth, altitude and latitude_{observer}. Four dimensions are difficult to visualize so we’ll use my latitude of 40.3245° north and analyze the other three variables graphically.

The vertical axis of the above surface plot illustrates the angular velocity of the field rotation, in degrees per second, for various values of azimuth (horizontal axis) and altitude (depth axis). There are several interesting insights worth pointing out. First, at altitudes less than 65° the field rotation never exceeds 0.01° per second regardless of the azimuth chosen. Second, the field rotation never exceeds 0.01° per second for altitudes up to 75° for azimuths between 240° and 300° and 60° and 120°. In other words, looking due east or due west is far better than looking north or south. Finally, looking north or south results in high rates of rotation.

This section has illustrated the mathematical theory governing field rotation. While the math is fairly straightforward, the results are more complicated than one may have initially thought. In the next section, we’ll determine the impact field rotation has on astrophotography for our specific system and reexamine the surface plot above in terms of safe and ill-advised zones for various exposure lengths.

Impact on Astrophotography

For long exposures using imaging systems attached to alt-azimuth or poorly aligned equatorial mounts, field rotation is an issue that degrades image quality. In the previous section, we presented an approach to determine the angular velocity of the field rotation for a given latitude, azimuth and altitude. In this section, we’ll use that information to quantitatively determine how field rotation impacts image quality using systems with various characteristics.

Acceptable Field Rotation

Imaging system characteristics such as focal length, aperture, f-number, exposure length, sensor size and pixel size play important roles in astrophotography. The characteristics that determine the level of impact field rotation has on image quality are focal length, the size of the sensor and the associated pixels. The following figure is a representation of an image sensor made up of a two-dimensional array of pixels. The green, yellow and red disks represent seeing disks projected onto the sensor with angular sizes of 1″, 2″, 3″ and 4″ respectively. This is to scale for a sensor with a pixel size of 4.78µm and a system focal length of 560mm. The sizes of these disks are proportional to the focal length of the system as described below.

    \[ Size_{disk} = \frac{2\pi}{360°} \theta_{disk} \times Focal\;Length \]

where Size_{disk} is the size of the seeing disk on the sensor in meters, \theta_{disk} is the angular size of the seeing disk in degrees and Focal\;Length is the focal length of the optical system in meters. The four seeing disks illustrated on the sensor are approximately 2.71µm, 5.43µm, 8.14µm and 10.86µm in diameter.

While an image is being exposed, the field is rotating at an angular velocity \omega_f. For a specific exposure time, time_{exposure}, the angle of image rotation \theta_f can be computed as \theta_f = \omega_f \times time_{exposure}. While all objects in the field of view rotate around the center at the same angular velocity, those furthest from the center cover more distance. To ensure good image quality, the distance travelled must be less than a few pixels on the sensor. In the next section, we’ll try and quantify how much image rotation can be tolerated while still achieving esthetically pleasing results.

The Rule of 500

To determine just how many pixels can be traversed without significant impact, we’ll turn to the rule of 500 used by photographers to image the night sky. It should be noted that this rule was not developed to deal with field rotation, but rather to deal with star movement relative to a stationary camera. However, it does suggest the amount of movement that can be tolerated and still yield pleasing results. This rule of thumb suggests that the maximum length of an exposure, without significant star trails, is computed by dividing 500 by the focal length of the system measured in mm. The angular distance a star image travels across the sensor in this length of time is derived below.

    \[ \theta_{star} = \omega_{earth} \times time_{exposure} \]

where \theta_{star} is the angular distance in degrees traveled by a star in time_{exposure} measured in seconds given that the earth is rotating at the angular velocity of \omega_{earth} measured in degrees per second.

According to the rule of 500 an appropriate exposure time is 500 divided by the focal length of the optical system measured in mm,

    \[ \theta_{star} = \omega_{earth} \times \frac{500}{Focal\;Length} \]


    \[ \theta_{star} = \frac{\omega_{earth}}{2 \times Focal\;Length} \]

where Focal\;Length is now measured in meters. By determining the fraction of the sensor that \theta_{star} represents and multiplying it by the number of pixels, we’ll get the number of pixels traversed when applying the rule of 500. To start with we know that,

    \[ FOV = \frac{360°}{2\pi} \frac{Sensor\;Size}{Focal\;Length} \]


    \[ Pixel\;Count = \frac{Sensor\;Size}{Pixel\;Size} \]

where FOV is the field of view projected onto the sensor measured in degrees, Sensor\;Size is the size of the sensor in a particular dimension measured in meters, Focal\;Length is the focal length of the system measured in meters, Pixel\;Count is the number of pixels in the same dimension as mentioned above and Pixel\;Size is the size of one pixel, measured in meters.

Dividing \theta_{star} by FOV and multiplying by Pixel\;Count} we obtain,

    \[ \frac{\theta_{star}}{FOV} \times \frac{Sensor\;Size}{Pixel\;Size} = \frac{\frac{\omega_{earth}}{2 \times Focal\;Length}}{\frac{360°}{2\pi}\frac{Sensor\;Size}{Focal\;Length}} \times \frac{Sensor\;Size}{Pixel\;Size} \]

Simplifying we obtain,

    \[ \frac{\theta_{star}}{FOV} \times \frac{Sensor\;Size}{Pixel\;Size} = \frac{\pi}{360°}\frac{\omega_{earth}}{Pixel\;Size} \]

Finally, we recognize that \frac{\theta_{star}}{FOV} \times \frac{Sensor\;Size}{Pixel\;Size} is simply the number of pixels traversed by the seeing disk on the sensor, resulting in

    \[ Pixels_{traversed} =\frac{\pi}{360°}\frac{\omega_{earth}}{Pixel\;Size} \]

where Pixels_{traversed} are the number of pixels that can be traversed without leaving significant star trails according to the rule of 500, \omega_{earth} is the rotational velocity of the earth in degrees per second and Pixel\;Size is the size of each pixel in meters.

A sidereal day is 23 hours 56 minutes and 4.1 seconds or 86,164.1 seconds long. The earth rotates through 360° in this length of time resulting in \omega_{earth} being approximately equal to 0.00418° per second.

For a pixel size of 4.78µm, the rule of 500 suggests that 7.63 pixels can be traversed. We’ll round down to ensure better image quality. For the remainder of this work we’ll assume that if a seeing disk traverses 7 or fewer pixels across the sensor, due to field rotation, the image quality will be acceptable.

It is important to keep in mind that the rule of 500 has nothing to do with field rotation. However, photographers have used this rule to achieve good results shooting the night sky without significant star trails in their photographs. If stars traversing 7 pixels in these photographs are not objectionable, they shouldn’t be in our images either.

Acceptable Viewing

In the previous section we determined that star images traversing 7 or fewer pixels across the sensor would be acceptable. In this section we’ll investigate what impact we can expect due to field rotation and determine where in the night sky it is safe to image without having elongated stars in our photographs.

Given a rectangular image sensor, the distance an object travels in terms of rotational velocity and distance from the center of the sensor is described by,

    \[ D = \frac{2 \pi R}{360} \times \omega_f  \times time_{exposure} \]

where D is the distance in meters an object travels across the sensor at a distance R from the center of the sensor, R is the distance from the center of the sensor to the object of interest in meters, \omega_f is the field rotational velocity in degrees per second and time_{exposure} is the length of the exposure in seconds. Combining our initial equations for \omega_f with this equation we have,

    \[ D = \frac{2 \pi R}{360} \omega_{earth} \times \cos latitude_{observer} \times \frac{\cos azimuth}{\cos altitude}  \times time_{exposure} \]

where D is the distance an object travels across the sensor in meters, R is the distance from the center of the sensor to the object of interest in meters, \omega_{earth} is the angular velocity of the earth’s rotation in degrees per second, latitude_{observer} is the latitude where the observations are made, azimuth and altitude describe the coordinates of the celestial body of interest in degrees and time_{exposure} is the length of the exposure in seconds.

Let’s consider the characteristics of a specific CMOS sensor, the IMX071. This sensor is 23.6mm x 15.6mm with a 28.4mm diagonal. The pixel size of this sensor is 4.78µm and they are organized in a two-dimensional array that measures 4944 x 3284 pixels. While objects at the extreme corners of the sensor are not captured as they rotate through the field, their distance from the center is a good worst case measure since they travel further than anything else in the field for any given time_{exposure}.

If we assume the same latitude_{observer} of 40.3245° north as before and an exposure time of 10 seconds, we obtain the surface below. The vertical axis is the number of pixels traversed during a 10 second exposure, the other two axes represent the azimuth and altitude of the observed object.

For good image quality it is important to have as little movement as possible, but less than 7 pixels according to the rule of 500 discussed in the previous section. The following figure illustrates azimuths and altitudes that result in good 10 second exposures at a latitude of 40.3245° north.

The green area illustrates where pixel traversals of 7 pixels or less occur. The yellow areas have pixel traversals of 7 to 14 pixels and the red regions represent pixel traversals greater than 14 pixels.

For altitudes less than 75°, acceptable images can be acquired at any azimuth value. Between 70° and 110° azimuth and 250° and 290° azimuth, acceptable images can be obtained at altitudes up to 85°. There are few restrictions for 10 second exposures. Also recall that these values are based on the very corner of the sensor where field rotation has the biggest impact.

The next two figures illustrate azimuths and altitudes that result in good 20 and 30 second exposures at a latitude of 40.3245° north.

Exposure times of 30 seconds result in far more restrictions. The poles should be avoided above 45° and only due east and west are virtually unrestricted.

As stated earlier, there is no field rotation at the poles of the earth. The equatorial region suffers the most field rotation. The following figure illustrates azimuths and altitudes that result in good 10 second exposures at the equator, latitude 0°.As previously stated, moving from a latitude of ~40° to 0° has little impact on the effects of field rotation. There are no restrictions below 70° of altitude and almost no restrictions in the vicinity of due east and due west.

In this section we discussed and visualized the impact of field rotation on astrophotography and discussed where in the sky it is acceptable to image. In the next section we’ll discuss these results as they apply to a specific use case.

Celestron CPC 1100 GPS XLT

In the previous sections we have described field rotation and determined its impact on astrophotography in terms of azimuth, altitude, latitude and exposure time. In addition, we have hypothesized, using the rule of 500, that star images can cross 7 or fewer pixels on the image sensor without significantly degrading image quality. In this section, we’ll investigate how this impacts images captured using a Celestron CPC 1100 GPS XLT telescope on an alt-azimuth mount. Finally, we’ll determine under what circumstances this configuration can successfully capture images of deep space objects (DSO).

Specific Configuration

The system of interest is a Celestron CPC 1100 Schmidt-Cassegrain telescope mounted in its standard alt-azimuth mount. The system includes a Hyperstar 3 lens system and a ZWO ASI071MC Pro camera. The Hyperstar system replaces the secondary mirror of the telescope and results in an optically fast f/2 system with a focal length of 560mm.

The ZWO ASI071MC Pro camera uses the IMX071 sensor that measures 23.6mm x 15.6mm with a 28.4mm diagonal. The pixel size of this sensor is 4.78µm and they are organized in a two-dimensional array that measures 4944 x 3284 pixels.

Astrophotography Limitations

An f/2 optical system is quite fast, which allows shorter exposure times than used by astrophotographers using more traditional f5.6 or slower refractor telescope systems. In fact, an f/2 system is 8 times faster than an f/5.6 system. While there is much debate around the optimal exposure time of sub-exposures used in stacking, there are many who use 2 to 5 minute sub-exposure times with f/5.6 systems. Compared to an f/5.6 system, an f/2 system can collect the equivalent amount of light in 15 to 37.5 seconds.

Given my latitude of 40.3245° north, our use of the rule of 500 and the above information we can once again refer to the following figure. Again, the green area of this figure is where the field rotation results in fewer than 7 pixels being traversed at the corner of the sensor during a 30 second exposure. The yellow and red regions violate the rule of 500 for this long of an exposure.

On our f/2 system a 30 second exposure is equivalent to a 4 minute exposure on an f/5.6 system. This should be satisfactory for sub-exposure times for many DSOs. The green area in the above figure represents azimuths and altitudes where we can expect good results. We should have good results anywhere below an altitude of 45°. Since seeing is generally not ideal below an altitude of 30°, we should expect to find success at any azimuth between an altitude of 30° and 45°. We can also find success at azimuths from 55° to 125° and 235° to 305° for altitudes up to 65°. Due east and west we have virtually no limitations.

While the exposure times discussed above result in acceptable field rotation within a give sub-exposure, there will be significant field rotation over the set of sub-exposures that will be stacked during post processing. Removing this field rotation requires the stacking algorithm to align stars using both translation and rotation. Nebulosity 4 can perform star alignment using translation, rotation and scaling. I’m confident other tools can as well.


Alt-azimuth mounted telescopes used for astrophotography suffer from field rotation. Field rotation causes star images on the sensor to circle around the center of the field of view. To achieve acceptable results the amount of movement must be minimized. The rule of 500 suggests that if 7 or fewer pixels are traversed during an exposure, the outcome in terms of star trails will be acceptable. For 10 second exposures, there are few limitations on where in the sky an object can be photographed. As the exposure times increase to 30 seconds far more restrictions exist, but success can be found.

Several obvious things can be done to improve the likelihood of acquiring acceptable results. First, imaging where field rotation will result in 7 or fewer pixel traversals will help. These areas are identified in the previous graphs. Second, the shorter the exposure times the better. While 30 second exposures have a few unacceptable areas of the sky, 10 second exposures have virtually no limitations. Finally, since field rotation issues decrease as you move towards the center of the sensor, cropping acquired images will help.

For our Celestron CPC 1100 GPS XLT at ~40° north latitude operating in an f/2 configuration, there are few limitations when taking 10 second exposures. Since f/2 is 8 times faster than a typical f/5.6 refractor telescope used for astrophotography, 30 second exposures, or even shorter, will likely result in acceptable sub-exposures. Now it is time to collect data and see how accurate these findings are.

Astrophotography Camera Selection Notes


There are numerous issues to consider when choosing a camera for astrophotography. Consideration must be given to the type of astrophotography of interest, the specifications of the chosen telescope, and the camera style, technology and sensor specifications. This document addresses these issues in general terms and illustrates specifics based on an example telescope, a Celestron CPC 1100 GPS XLT.

Objects of Interest

The two types of astrophotography investigated in this document are planetary imaging and deep space object (DSO) photography. Planets and DSOs have unique characteristics that demand different approaches for capturing aesthetically pleasing images. The two characteristics that most influence the employed methodologies are apparent size and brightness.

The apparent size of celestial objects are measured in arc-seconds. The celestial sphere, like a circle, has an angular circumference of 360°, read as 360 degrees. Each degree can be subdivided into 60’, read as 60 arc-minutes, and each arc-minute can be subdivided into 60”, read as 60 arc-seconds. For reference the apparent size of our sun and moon are approximately 32’ or 1920”. The planets range in apparent size from Neptune at 2.21” up to Jupiter at 40.95”. In comparison DSOs in the Messier Catalog range in apparent size from M40 at 48” up to M31 at 10,680” or 178’.

The apparent brightness of celestial objects are measured in magnitude (m) as observed from earth. The brightness of an object can be measured in various wavelengths of the electromagnetic spectrum. We’ll restrict our interest to the visible spectrum where magnitudes are denoted mv. Brighter objects have lower magnitudes, it’s an inverse relationship. The brightest object in the sky is the sun at magnitude -27 or mv = -27. The magnitude scale is logarithmic. A difference in magnitude of 1 is equivalent to a change in brightness by a factor of \sqrt[5]{100} or approximately 2.512. The magnitudes of the planets range from Neptune at mv = 7.96 up to that of Venus at mv = -3.86. However, the most imaged planets range in brightness from Mars at mv = 0.56 up to Venus at mv = -3.86. In comparison the DSOs in the Messier Catalog range in magnitude from M91 at mv = 10.2 up to M45 at mv = 1.6. However the second brightest item in the Messier Catalog is M7 at mv = 3.3, illustrating that M45 is a bright exception.

With regard to astrophotography, the planets are very small and relatively bright objects, while DSOs are huge in comparison and very dim. These differences lead to different imaging strategies which in turn influence equipment configuration and technology choices.


There are many types and sizes of telescopes. This document will not attempt to describe the various types or their strengths and weaknesses. Instead, it will cover basic configuration parameters that impact the imaging of planets and DSOs. From the previous discussion it should be clear that a large field of view is important for imaging DSOs and high magnification is essential for photographing the planets. These are competing requirements in terms of telescope specifications.

The aperture of a telescope is the width of the primary mirror or lens. Larger apertures are capable of resolving finer detail and collecting more light, resulting in lower exposure times. The focal length is the distance from the primary mirror or lens to where the image is focused. Longer focal lengths result in more magnification and narrower fields of view. The f-number, or speed of the telescope, is determined by dividing the focal length by the aperture. For a given aperture, planetary imaging demands a large f-number where high magnification is obtained. For imaging DSOs a low f-number yields less magnification and a greater field of view.

Astrophotographers acquire telescopes with as much aperture as they can afford and physically handle. Those photographing DSOs tend to acquire moderately sized apochromatic (APO) refractor based telescopes with f-numbers in the f/5.6 to f/7 range. They often add a focal reducer to further decrease the effective f-number. Those photographing planets tend to acquire telescopes with longer focal lengths and employ Barlow lenses to increase the focal length by a factor of 2, 3 and even 5.

Telescopes like the Celestron CPC 1100 GPS XLT have a large 280mm aperture. The Schmidt-Cassegrain telescope (SCT) design results in a focal length of 2800mm and an f-number of f/10. This configuration results in a narrow field of view and relatively long exposure times for faint DSOs. The addition of a Barlow lens to this configuration results in a system that is ideal for planetary imaging. Fortunately, Celestron included a removable secondary mirror to the CPC 1100 system that can be replaced by a lens system called Fastar or Hyperstar. These systems convert the telescope from a relatively slow f/10 system to a fast f/2 imaging system. In this configuration the CPC 1100 has a focal length of 560mm and a huge field of view of just over 2.76°. This convertible feature makes the CPC 1100 useful for both planetary and DSO imaging.


There are many choices to be made when selecting a camera for astrophotography. These choices include the camera form factor, the sensor technology and detailed specifications such as sensor size, pixel depth and pixel size.

Camera Form Factors

While there are commercially available cameras specifically deigned for astrophotography, many photographers use modified DSLR cameras. The beneficial modification entails removing the infrared filter that sits permanently over the sensor of the camera. This renders the camera less than useful for regular photography, but allows the camera to be more sensitive to the wavelength of light produced by Hydrogen-alpha emission nebulae. These cameras may be used with nearly any telescope, but when placed in front of the optical path, using a system like Fastar or Hyperstar, the size and shape of the camera may block an unacceptable amount of light and introduce diffraction artifacts in captured images.

Many dedicated astrophotography cameras have better form factors that permit them to be connected within the optical path without negatively impacting the amount of light entering the system. In addition, many of these cameras are cooled, reducing sensor noise and increasing the quality of the finished results. However, these cameras have connected cables that introduce unwanted diffraction patterns in images.

Sensor Technology – CCD or CMOS

Commercially available astrophotography cameras are available with CCD and CMOS sensors. CCD sensors have an edge over CMOS sensors in image quality, but CCD sensors have slower read speeds. High read speeds increase the frames per second (fps) that can be acquired by a camera. High frame rates are particularly important in planetary photography using lucky imaging techniques. This methodology requires many frames per second be taken in the hope of collecting images, or portions of images, less distorted by atmospheric turbulence. CMOS sensors are better suited for this technique.

For DSO photography the read speed is less important, but can reduce the overall session time. The near infrared portion of the spectrum is important in DSO photography and CCD sensors are more sensitive than CMOS sensors in this area. However, CMOS sensors, found in modified DSLR and commercially available astrophotography cameras, are adequate in this area and cost far less for the same pixel count. The remainder of this document will focus on CMOS sensor based technologies.

Sensor Specifications

To determine necessary camera specifications it is important to understand what is trying to be imaged. The next sections will describe the imaging of stars and how this impacts camera sensor specifications.

Star Images

Stars are far enough away and small enough in comparison to their distances from earth to be considered points of light. Ideally, these points of lights should be focused to points within an optical system, but due to diffraction and atmospheric turbulence they are not.

Due to diffraction, the smallest point to which a mirror or lens can focus a point source of light is the size of what is known as an Airy disk. The Airy pattern, named after George Biddell Airy, has a bright central region, the Airy disk, surrounded by concentric bright rings. A graphical representation of an Airy pattern is shown to the right. As a mirror or lens focuses a star, it will appear as an Airy pattern to the observer. In this case the vertical axis represents the intensity of the observed star light and the horizontal axis is a measure of the dimeter of the Airy pattern.

There is a lower limit to the diameter of an Airy disk for a particular mirror or lens. An optical system that has reached this level of perfection is said to be diffraction limited. Reducing system imperfections beyond this point do not reduce the diameter of the Airy disk. The radius of the Airy disk is approximately described by the following equation:

    \[ \theta = 1.22\times\frac{\lambda}{d} \]

where \theta is the radius of the Airy disk in radians, \lambda is the wavelength of light in meters and d is the diameter of the mirror or lens in meters. Our example telescope (a Celestron CPC 1100 SCT) is diffraction limited and has an aperture of 280mm. In ideal conditions this optical system would produce an Airy disk with a diameter of 0.97” for visible light with a wavelength of 540nm. So an ideal 280mm diffraction limited telescope, without an atmosphere between it and the observed star, would produce an Airy disk with a diameter of 0.97”.

Our atmosphere distorts star light traveling through it. These distortions often occur more than 100 times per second. For long photographic exposures (greater than a few seconds) this movement of the Airy disk results in a larger disk know as a point spread function or seeing disk. This disk is similar in shape to the Airy disk, actually a two-dimensional normal distribution, and its width, generally defined as the full width at half maximum (FWHM), is a measure of the seeing conditions. The best seeing from high altitude mountain observatories is reported to be approximately 0.4”. Most observers seem extremely content with FWHM of 1”, happy with FWHM of 2” and 3” and stop work above 4”. In the next section we’ll use a FWHM equivalent to the diameter of the Airy disk to determine the sensor requirements to accurately represent images captured during perfect observing conditions. If seeing is worse than ideal, the chosen sensor characteristics will be more than adequate.

Sensor and Pixel Size

CMOS sensors are available in a range of sizes with each containing a different number of light collecting elements or pixels. The size of the sensor and the number of pixels determine the pixel size. Sensor size is important because it influences the field of view (FOV) of collected images. Pixel size is important to ensure that the light from each star strikes enough pixels to be sampled properly.

The field of view of a telescope and sensor combination is described by the following equation.

    \[ FOV = \frac{Sensor\;Size}{Focal\;Length} \]

where FOV is the real field of view in radians, Sensor\;Size is the size of the sensor in one dimension, measured in meters, and Focal\;Length is the focal length of the optical system also measured in meters. The field of view of a single pixel FOV_{pixel} is,

    \[ FOV_{pixel} = \frac{\frac{Sensor\;Size}{Pixel\;Count}}{Focal\;Length} \]

where Sensor\;Size is the size of the sensor in one dimension measured in meters, Pixel\;Count is the number of pixels in the same dimension and Focal\;Length is the focal length of the optical system in meters. The ratio of Sensor\;Size to Pixel\;Count is simply the pixel size, Pixel\;Size.

    \[ FOV_{pixel} = \frac{Pixel\;Size}{Focal\;Length} \]

Nyquist sampling indicates that we need at least two samples of the seeing disk, or the Airy disk in our ideal case, to accurately represent it. Two samples is what is required of one-dimensional signals like audio, but for a two-dimensional system, like the one at hand, it is more like 3.3. In other words, FOV_{pixel} should be 1/2 to 1/3 the diameter of the Airy disk. We’ll use 1/2 for the remainder of this work which is equal to the Airy disk’s radius.

    \[ 1.22\times\frac{\lambda}{d} = \frac{Pixel\;Size}{Focal\;Length} \]

Solving this equation for Pixel\;Size and recognizing that Focal\;Length divided by aperture   is equal to the \text{f-number} of the system results in,

    \[ Pixel\;Size = 1.22\times \lambda \times \text{f-number} \]

For an f/2 optical system at 540nm, the ideal pixel size is 1.32µm while the same system operating at f/10 would have an ideal pixel size of 6.59µm. It is unlikely the seeing conditions will ever approach the ideal and will more likely result in FWHM values of between 2” and 4”. At these values the ideal pixel sizes for an f/2 system would be 2.72µm and 5.44µm respectively. For an f/10 system they would be 13.59µm and 27.22µm respectively.

Three commercially available CMOS sensors include the MN34230, IMX294, and the IMX071. These sensors have pixel sizes of 3.8µm, 4.63µm and 4.78µm respectively. These sensor pixels are not quite small enough to offer the ideal sampling at f/2 with good seeing, are satisfactory for imaging in poorer conditions and are more than adequate for imaging at higher f-numbers. In addition, beautiful images can be obtained without reaching these sampling goals, which are often less important for aesthetically pleasing pictures than a large field of view. With a focal length of 560mm these sensors yield fields of view of 1.81°, 1.95° and 2.41° respectively.

Sensor Dynamic Range

Each pixel of a CMOS sensor can only collect so much light energy before it reaches its maximum value or saturation. This point is called full well capacity. When a pixel value is read, it returns the measured intensity of light that struck the pixel and a small error. This read error (and dark current noise) subtracted from the full well capacity represents the dynamic range of the pixel and associated sensor. We’re assuming here that for cooled astrophotography cameras the dark current impact is negligible. This may not be the case, but for comparison purposes it is a reasonable approximation. High dynamic range is a desirable feature.

ADC Capacity

When light strikes a pixel in a CMOS sensor it generates a voltage. This voltage is sampled by an analog to digital converter that translates the voltage into a binary number. The set of binary numbers representing all pixels on the sensor represent the collected image. The number of bits representing each pixel defines how well subtle tonal changes in a scene will be preserved. More bits representing each pixel will result in a final image that is a better representation of the original scene. Typical sensors use 8-14 bits to represent each pixel.

Read Speed

Typically the larger a sensor is in terms of the number of pixels, the slower the read speed. Some sensors permit partitioning allowing portions of the sensor to be read, increasing speed. Read speed is related to frames per second that can be captured. Planetary imaging using lucky imaging techniques require many frames per second. Typical large CMOS sensors have full sensor read speeds between 10 and 30 frames per second. Reduced resolution reads can be done much faster.

Commercially Available Cameras

While there are many commercially available astrophotography cameras from numerous vendors, this document will illustrate just a few. The following table illustrates the specifications for cameras based on the MN34230, IMX294, and IMX071 CMOS sensors. Two of the cameras are based on the same sensor, but have slightly different specifications. In the next section we’ll consider which characteristic of each camera is a best match for our application.

 ASI1600MC ProASI294MC ProASI071MC ProQHY168C
Resolution16MP 4656 x 352011.3MP 4144 x 282216MP 4944 x 328416MP 4952 x 3288
Pixel Size 3.8µm4.63µm4.78µm4.78µm
Sensor Size17.7 x 13.4mm19.1 x 13mm23.6 x 15.6mm23.6 x 15.6mm
Sensor Diagonal22.2mm23.2mm28.4mm28.4mm
Capture Speed23 FPS19 FPS10 FPS10 FPS
Read Noise1.2 - 3.6e1.2 - 7.3e2.3 - 3.3e2.3 - 3.3e
Full Well Capacity20000e63700e46000e46000e
Dynamic Range (no dark current)75 db79 db83 db83 db
ADC12 bits14 bits14 bits14 bits
FOV @ 560mm FL1.81° x 1.37°1.95° x 1.33°2.41° x 1.6°2.41° x 1.6°
FOV per Pixel @ 560mm FL1.4"1.69"1.75"1.75"

Our Application

In this section we’ll consider each CMOS camera illustrated in the previous table and how it fits our application. We desire a camera that will be useful for DSO imaging in conjunction with a Fastar or Hyperstar system connected to a CPC 1100 GPS XLT telescope. We would also like to use the same camera for planetary imaging connected to the same telescope in its f/10 configuration augmented with Barlow lenses to increase the f-number to f/20 or f/30.

Form Factor

Each of the four cameras are cylindrical in shape with diameters that are less than the diameter of the secondary mirror of the Celestron CPC 1100 telescope. In other words, none of the cameras obstruct the useful aperture and all have the same cabling, causing unwanted diffraction. These cameras will also connect fine in the f/10 configuration.

Sensor and Pixel Size

In the f/2 configuration, with perfect seeing, we could use a pixel size of 1.32µm, but with realistic expectations of FWHM of 3”, Nyquist requires a pixel size of 4.08µm. Only the ASI1600MC Pro has a pixel size that meets this requirement. In the f/10 configuration, all of the cameras meet Nyquist’s requirement. In fact, the large pixel size of the two cameras using the IMX071 sensor would meet the sampling requirement down to f/7, using a focal reducer, with perfect conditions, and lower under realistic seeing.

Dynamic Range and ADC

The larger pixels of the ASI294MC Pro, ASI071MC Pro and the QHY168C result in higher full well capacities that in turn result in potentially better dynamic range. This is particularly important when operating at f/2 when bright stars within the large field of view may quickly saturate some pixels. In addition, these three cameras also have 14 bit ADCs that may result in slightly more accurate images.

Read Speed

The four cameras range in speed from a low of 10 fps to a high of 23 fps. However, each is capable of higher speeds at lower resolutions. For example, the QHY168C is capable of frame rates as high as 130 fps for 240 lines of resolution and 30 fps for 1920 x 1080 HD. These rates should be adequate for useful planetary imaging in good seeing conditions.

Best Fit

In this section we’ll refer to data in the above table and point out meaningful characteristics that are best met by the associated camera. The camera with the best pixel size that approaches proper sampling is the ASI1600MC Pro. However, none of the cameras have small enough pixels to meet the demands of Nyquist’s sampling requirements for ideal seeing conditions. As previously stated, beautiful images can be obtained without reaching the Nyquist sampling goals and these goals are often less important than obtaining a large field of view.

Since the field of view is directly related to the sensor size, the ASI071MC Pro and the QHY168C are the big winners. Their fields of view are nearly 1/2° wider than the next best camera. In addition, these two cameras have better dynamic range and have the same size ADCs.

In comparing the ASI071MC Pro and the QHY168C, the ASI071MC Pro has a larger memory buffer made of DDRIII instead of DDRII memory. It also achieves a slightly cooler temperature which should further increase its dynamic range beyond that of the QHY168C. The ASI071MC Pro includes a 2-port USB 2.0 hub, is 60g lighter and insignificantly smaller. Finally, the QHY168C is currently $181 less expensive than the ASI071MC Pro.

The following table illustrates the components that are necessary to use the Celestron CPC 1100 GPS XLT telescope for astrophotography. Note that the additional $181 for the ASI071MC Pro adds only 5% to the total cost of the project. This seems reasonable given the slight feature advantages it has over its competitor.

 ASI071MC ProQHY168C
Celestron HD Wedge$350$350
Hyperstar 3$999$999
10:1 Focuser$275$275
Bahtinov Mask$35$35


The convertible feature of the Celestron CPC 1100 GPS XLT telescope makes the system useful for imaging planets in its f/10 configuration, while its f/2 configuration, using Fastar or Hyperstar, yields a massive 2.7° field of view for imaging DSOs. While none of the reviewed cameras have small enough pixels to satisfy Nyquist sampling requirements for theoretical seeing conditions in the f/2 configuration, two of the four are adequate and yield 2.4° fields of view. For planetary imaging these two cameras easily meet the sampling requirements and have fast enough frame rates to support lucky imaging techniques. While the cost of the ASI071MC Pro is slightly higher than the QHY168C, the ASI071MC Pro reaches cooler temperatures, has a USB hub that may reduce wiring congestion, is 60g lighter and is slightly smaller. Overall, the ASI071MC Pro is our best fit.

TAN: Trailer Area Network


A friend of mine, Scott Lemon founder and CTO of Wovyn, and I were discussing my travel trailer API and he coined the term, trailer area network or TAN. My TAN is going to be based on WiFi because of the ubiquitous availability of WiFi connected devices including microcontrollers, commercially available connected devices, and mobile phones and tablets. To this network I’ll attach microcontrollers that control trailer subsystems. These subsystems will connect via WiFi to a trailer hub that will expose subsystem functionality through the travel trailer API, see Figure below.

In this figure Internet connectivity is acquired through a mobile hotspot with the help of a cell signal booster. The mobile hotspot allows 15 devices to connect to it. One of the 15 devices will be the TAN Hub. The TAN Hub will create a subnet that subsystems will attach to, there could be many. Communications between the subsystems and the TAN Hub may use various protocols, but the TAN Hub will expose their functionality through a REST based API.


There are three main sets of components that are needed to create the described TAN. For Internet connectivity we need a signal booster and a mobile hotspot. We need a server of sorts to act as the TAN Hub and a WiFi connected microcontroller unit to use in the construction of subsystems.

Internet Connectivity

I have selected the AT&T Unite Explore, also known as the Netgear AC815S, device as my mobile hotspot device. It seems to get good reviews and is reasonably priced. I may experiment with other hotspots in the future.

I acquired a weBoot Drive 4G-M Cell Phone Signal Booster to facilitate the acquisition of cell signals in remote locations. In the future I may experiment with various antenna configurations to increase the usable range.

Trailer Area Network Hub

For the TAN Hub I will use the Corewind WiFiG25 microcontroller module described in my original post describing my trailer API. This module is based on a 400 MHz ARM processor, has ample memory, and built in WiFi and runs the Linux operating system.

I expect to add an API management system to this module and communication systems to enable it to connect to and communicate with trailer subsystems.

Subsystem Controllers

There are many potential trailer subsystems that can be exposed and interacted with through an API. Examples include: leveling jacks, stabilizers, tank levels, battery levels, solar energy generation, awning, pop-outs, security, weather data, etc. Each of these will inevitably require special sensors, actuators, etc., but I am hoping to standardize on the microcontroller modules used to control the subsystems and communicate to the TAN Hub.

I will be experimenting with the ESP 12-F module based on the ESP8266 chip. This is an impressive module featuring a 32 bit MCU, integrated WiFi, tcp/ip stack, 4 MBytes of Flash memory for user programs, and all this for $1.74. It is capable of communicating with other hardware using SPI, I2C, Serial and other low level communication protocols.

These communication channels, as well as the available GPIO lines, will be used to interface these modules to subsystem specialty hardware such as switches, sensors, etc. The integrated WiFi will be used to connect these subsystems to the TAN Hub.


Future posts will describe various details related to the programming, configuration, and use of the components discussed in this post. There is much to learn, much to do, and a lot of fun to be had.

Travel Trailer API


I have recently purchased a travel trailer and desire to instrument and automate it. I want to control and monitor all of its systems using my iPhone or other mobile devices. When I am out in the sticks (defined by my son to be wherever there is no Internet connectivity) I want to connect to the trailer’s systems via a local WiFi network. When the trailer is in a location where LTE, or other data services are available, I want to interact with the trailer via the Internet.

While there are many systems to monitor and control, there are two fundamental technological pieces they all require. First, a WiFi network must be provided for mobile phones and other devices to connect. Second, a central controller is needed to manage the myriad of systems that will be connected to this network and manage the associated API.

Rather than boiling the ocean, I intend on focusing on one simple representative system, a weather station, and connecting it to our trailer. Success with this system requires solving many issues that will simplify the inclusion of additional systems in the future. The rest of this post will describe a path forward. A series of future posts will describe the details associated with each subsystem.

System Description

The goal of this project is to enable a mobile phone user to view weather data acquired from a weather station connected to our travel trailer. There are a number of modules or subsystems required to accomplish this:

  1. A mobile phone that connects to a WiFi network and an application that consumes an API that returns weather station data.
  2. A secure WiFi network or trailer area network (TAN). While security of weather station data may not be required, future projects will require it and we should design with security in mind.
  3. A central controller that connects to the provided TAN and exposes an API management tool. This will enable mobile phones and other devices to access available data in a secure and managed way.
  4. A 433 MHz receiver connected to a microcontroller based module will convert the signal acquired from the weather station into an appropriate API.
  5. A weather station that transmits collected data on the 433 MHz band.

The weather station will collect environmental data and transmit it over the 433 MHz radio frequency band. This signal will be acquired using a 433 MHz receiver that converts this analog signal to digital for consumption by a microcontroller based system. The digital signal will be parsed appropriately and exposed through an API. This API will be managed by the central API management system and exposed to other devices over trailer area network. The mobile phone will consume this API and an appropriate mobile phone app will present it to the user.

Chosen Components

There are many possible components to choose from to accomplish the goal and steps outlined above. The components I’ve chosen and describe below are simply representative of the myriad of possible choices.

Weather Station

I will use the AcuRite 5 in 1 Professional Weather Center model 01536. This product is compact, easily mounted on a trailer and broadcasts weather data on the 433 MHz band. The outdoor component measures the temperature, humidity, rainfall, wind speed and wind direction. This data is combined into a packet and broadcast periodically. The indoor component is a nice color display that displays this data and archives previously received data. The indoor and outdoor components are paired through a simple channel selection mechanism.

433 MHz Receiver

I acquired the Sunkee 433 MHz superheterodyne wireless receiver module to convert the analog signal broadcast from the weather station into a digital signal appropriate for consumption by a microcontroller based system. This module can operate from roughly 3 to 5 Volts and requires a simple wire antenna. It outputs a digital signal easily read by standard microcontrollers.

Microcontroller System

I have chosen to use the Corewind WiFiG25 microcontroller module. It has a 400 MHz ARM processor, plenty of memory, built in WiFi connectivity, numerous I/O lines of various types, runs the Linux operating system, supports many programming languages, and only costs about $30.

Software Components

With the receiver connected to the microcontroller module, the rest is up to the software. A simple program will be written to acquire the digital I/O data from the receiver and store it in memory. The Kong API management tool will be implemented on the microcontroller to expose the collected weather data via an API. This API can then be consumed over the WiFi network by a mobile phone and associated application and our task will be complete, for now.


The components described above, and a few others, will be combined to expose weather data via an API for consumption by mobile phones and potentially other devices. The next post will describe the setup and use of the receiver module and a description of the data collected from the weather station. A series of posts will follow describing the remaining steps to accomplishing our goal.

myDoorbell: Play that Tune


In a previous post, I described the nine modules that make up myDoorbell. These are shown in the following figure. In this post I’ll address two modules that are difficult to describe separately, the microcontroller near the center of the figure and the MP3 decoder to its right.

Basic Operation

In my previous post I described a circuit that will translate a doorbell button press to a signal appropriate for consumption by the microcontroller. When this signal is received by the microcontroller, it takes two actions:

  • It raises a signal to the second microcontroller enabling it to raise external events. These events will be discussed in a future post.
  • It reads a MP3 encoded audio file from the memory and writes it to the MP3 Decoder module.

The MP3 Decoder module receives the streamed data from the microcontroller and decodes it, resulting in a small signal audio output.

The Microcontroller and Software

The microcontroller chosen for this application is the Atmel Atmega 328P. This processor is simple to use, relatively inexpensive and more than meets the requirements for this portion of myDoorbell. The schematic below illustrates the circuit used for this application. The labelled input and output signals are grouped into several main functions:

  • Input from the doorbell button detection circuit described in the previous post.
  • Output signals to the second microcontroller.
  • Serial Peripheral Interface (SPI) signals for communicating to the MP3 decoder and programming this microcontroller
  • Memory control and data signals
  • MP3 decoder control and data signals
  • An external clock running at approximately 8 MHz.
    • EXT_CLK 

The LED and the associated current limiting resistor are available as a programmable output that is easily visible. This can be used to indicate state or for initial debugging. The push button enables the device to be manually reset. The capacitors are 0.1 µF devices that act as bypass capacitors, see Basics to Remember below. The six pin header, in the upper right corner of the schematic, is for programming the microcontroller.

The software that drives the signals identified above can be found in the myDoorbell repository on While there is considerable amount of detail, that is best addressed by viewing the source code, a brief overview is useful.

The “main” routine initializes the memory module and the MP3 Decoder module by communicating with them over the identified control and data lines. This communication takes place using the SPI protocol. This routine then loops checking the state of the front and rear doorbell buttons and requesting or relinquishing control of the memory device to / from the second microcontroller.

If the front or rear doorbell buttons are pressed, the microcontroller accesses its built in EEPROM to determine the volume at which the ringtone should be played. It then plays the appropriate ringtone for the front or rear door.

The ringtone is played by determining its length and repeatedly reading portions of it from the memory and streaming it to the MP3 decoder. When the data is consumed the device goes back to checking the state of the doorbell buttons.

The MP3 Decoder

The MP3 decoder is based on the VS1011 MP3 Audio Decoder. The following schematic is recreated from it datasheet.

The input and output signals, on the left of the schematic, are connected to the identically named signals from the microcontroller schematic already presented. The outputs on the right are the two audio output signals and the common between them. Lots of bypass capacitors and a few other components, as illustrated in the datasheet, are included.

The VS1011 is capable of consuming MP3 and WAV formatted audio files and generating low level audio output. The audio output is sufficient to drive a pair of headphones, but in our application will drive an audio amplifier and associated speaker.

A Failed First Attempt 

The first design had a serious flaw that only manifested itself when in use. This misstep led to the design described in this post. However, since this design was put into use, two others have been proposed and will be described later.

The first design had a single microcontroller that interacted with the WiFi module, the doorbell button circuitry, the memory and the MP3 decoder. There was a major issue with this approach. When the doorbell button was pressed, should the MP3 file be played before an event is sent to the user, such as a text message, or should the event be raised and then the ringtone played?

If the event is sent first it will delay the playing of the ringtone by at least hundreds of milliseconds, but often much more. This doesn’t sound like much, but when you push a doorbell button you expect to hear the bell. In practice it was very odd to push the button and not get immediate feedback.

If you play the ringtone first and then send an event it works great, unless someone picks a 30 second ringtone. In this case, by the time you receive the text message and arrive at the door, the person is long gone. I have personally found that this behavior is often a feature, but others disagree.

This issue led to the design described here where we have two processors that communicate via shared signals and a shared memory. This approach is obviously more complex and more expensive.

Physical Implementation

The schematic for the microcontroller shown above resulted in the following PCB layout.

This design required a few traces to be routed on the bottom layer. As with previous PCBs illustrated in this series of posts, this one also utilizes a 4-layer design with internal layers carrying ground and 3.3 V. The reset button is on the far left, the microcontroller in the center and its programming header on the right.

The schematic for the MP3 decoder, illustrated above, results in the following 4-layer PCB. The crystal that controls the clock for this unit is located on the left of the layout. Most of the input and output lines are located at the bottom of the board. The low level

audio output interface is located on the right. As in previous layouts, bypass capacitors and other components are placed as close to the device as possible. 

Two Alternative Designs

The first alternative design is based on the initial single CPU misstep. In the first design the problem was dealing with which came first, the raising of external events or the playing of the ringtone. A better approach may be to send the MP3 decoder the first 32 bytes of MP3 data and then start raising the external event. The MP3 decoder has a data request (DREQ) line that gets asserted whenever the decoder is capable of receiving another 32 bytes of MP3 data. If this were tied to the microcontrollers interrupt line it could be used to direct the microcontroller to send more audio data and then return to raising the event. The only question is whether the 8 MHz microcontroller is fast enough to switch between the two tasks and accomplish what needs to be done without introducing gaps in the ringtone.

Back of the envelope analysis to figure out if this would work goes something like this. Good quality stereo MP3 files are about 1 Mbyte per minute in size. Since we only need one channel we can reduce the file size to 500 Kbytes per minute. We can clock SPI data into the MP3 module at 4 MHz or 4 Mbits per second. With 8 bits per byte this translates to 500 Kbytes per second. With switching time between tasks and other overhead this won’t work, but it is likely that we can get by with far less quality than we expect from our digital stereo music. Reducing the quality will likely make this technique possible.

The second alternative design takes a radically different approach. For this approach we trade out the WiFi module, both microcontrollers, memory, and the MP3 decoder and replace it with a fast embedded ARM microcontroller that runs the Linux operating system. An example of this is the Onion, shown below.

The microcontroller runs at 400 MHz instead of 8 MHz, giving us plenty of horsepower to accomplish our task. The Linux operating system provides the task switching necessary to switch rapidly between raising external events and playing ringtones. Audio playback software can be used instead of the dedicated MP3 decoder hardware currently being used. Finally, this sort of board costs less than $20, which is less than the WiFi module used in the current approach. This approach is currently being pursued.

In my own defense let me state that these sorts of modules were not available when the first design was completed. In addition, education leads to doing things in a better way; I’ve learned a lot!

Outcomes and Artifacts

There are likely many ways to build this portion of myDoorbell and a few of them have been described. The Eagle schematic and PCB files are available from the myDoorbell repository at

Basics to Remember

Bypass capacitors are used in many digital systems. Each clock cycle a digital system has the potential to change from one state to another. When this occurs the device draws significantly more current for a very short period of time. Recall that every wire acts like an inductor and that inductors resist changes in current. If the PCB trace from the device to the power source is long or narrow it will restrict current sufficiently to starve the device from the energy that it needs during these transition periods. Bypass capacitors hold sufficient charge to supply the device with the needed energy during these short periods of time. They are recharged while the device is relatively stable. These capacitors should be located as close to the device as possible and located between the power source and the device. This close proximity will reduce the inductance of the connecting trace.

myDoorbell: The Button


In my previous post, I described myDoorbell’s power supply module. In this post I will describe the circuitry that translates a standard doorbell button press into something that can be easily consumed by a microcontroller.

Standard Operation

The standard doorbell circuit is shown in the following figure. Recall that when the doorbell button is not pressed (open), current flows from the transformer, through the lamp, and through the solenoid, completing the circuit. With the doorbell button open, my test setup has approximately 50 mA of current. When the button is pressed (closed) a larger current, approximately 1 A, flows through the circuit.

myDoorbell is complicated by the system requirement to use the existing doorbell button and retain the functionality of its lamp.

myDoorbell Button

The figure above can be represented by a schematic where the lamp is replaced by a 320 Ω resistor. We model the lamp with this value resistor because with 16 Vrms across it,  the current flow is ~50 mA.

myDoorbell does not need the solenoid in the above circuit. However, if we simply replace it with a wire we will create a short circuit when the button is closed. In this case, approximately 0 Ω will exist, resulting in nearly infinite current, a bad idea. So replacing the solenoid with a resistor, to limit current, is necessary, but what value still needs to be determined. A large value resistor will result in little current, which is attractive, but too little current and the lamp won’t be bright enough to be useful.

As previously discussed, resistors have resistance values measured in Ω’s, but they are also rated for the amount of power they can dissipate. The power dissipated by a resistor is equal to the product of the voltage across it and the current through it. Through manipulation of Ohms Law it can be shown that the power dissipated by a resistor is also equal to the product of its value and the square of the current through it. With this in mind, if we choose a low value resistor its power rating will need to  be increased.

For example, if we choose a 10 Ω resistor, for the top resistor in the above figure, then approximately 48 mA will flow through the lamp when the button is open. The 10 Ω resistor will have to dissipate 0.02 W, well below the 0.1 W rating typical for small surface mount resistors. However, when the button is closed 1.6 A will flow through the circuit and the resistor must dissipate 25.6 W, it’s going to catch fire!

Let’s choose a higher value resistor, say 10 kΩ. Now when the button is open approximately 1.6 mA of current flows through the circuit resulting in the 10 kΩ resistor dissipating just 0.02 W, which is great, but the lamp will be very dark, bad!

So let’s compromise. We’ll choose a 220 Ω resistor that results in a current flow of 29 mA and a lamp that is visible when the button is open. In this mode the 220 Ω resistor will dissipate 0.185 W. This will require a larger resistor, but manageable. When the button is closed the 220 Ω resistor results in a current of nearly 73 mA and a power dissipation of 1.17 W. This will require quite a large surface mount resistor, but is necessary to meet our design requirements.

Detecting the Press

When the button is open, the voltage across it is equal to 320 Ω * Ilamp. Where Ilamp is equal to 16 Vrms / 540 Ω, or 29 mA. So the voltage across the button when it is open is 9.48 Vrms. When the button is closed, the voltage across it is 0 V. What we need is a circuit that detects this difference and generates a DC voltage appropriate for an input to a 3.3 V microcontroller. The figure below depicts just such a circuit. 

To the left we see the portion of the circuit described earlier, consisting of the transformer, push button, the 320 Ω resistor representing the lamp, and the 220 Ω resistor added to restrict the current flow when the button is closed. The circuitry to the right needs explaining.

Let’s start with the component outlined in the rectangle, an optocoupler. This device consists of a LED that emits infrared light onto a light sensitive driver. When the input current is sufficiently high, infrared light is emitted by the LED, and the output of the driver is pulled to ground. When the input current is sufficiently low, the output is left in an “open collector” state where no current flows. With no current through the output resistor, there is no voltage drop across it. In this state, the output level is equal to the voltage attached to the other side of the output resistor, in our case 3.3 V. A representative device is the H11L1M. Its datasheet can be found here.

In our application, when the doorbell button is closed there is 0 V across the LED of the optocoupler and the output will be 3.3 V. When the button is open the 320 Ω resistor, representing the lamp, will have 9.48 Vrms across it. The peak voltages are -13.4 V and 13.4 V. According to the optocoupler’s datasheet, its LED cannot tolerate reverse voltages exceeding 6 V, so the external diode is added to protect it. The external diode conducts when the input voltage is negative, resulting in roughly 1 V across the LED. 

Again referring to the datasheet, we need 1.6 mA of forward current on the LED to get the device to activate, driving the output low. As the input voltage rises from 0 V to 9 V we’ll allow the output to remain high, but when it arrives at 9 V we’ll switch the output to low. This will result in a 60 Hz sequence of 3.3 V pulses while the button is open. To accomplish this we need the optocoupler input current to be less than 1.6 mA with input voltages less than 9 V, and greater than 1.6 mA when the input voltage are higher.

Imagine we don’t know the value of the 5600 Ω resistor in the above circuit. To meet the requirements described in the previous paragraph, we need to size this resistor appropriately. If there is 9 V on the left of the resistor and 1 V on the right side, due to the forward voltage drop VF across the LED, there is 8 V across the resistor. This is explained by Kirchhoff’s Voltage Law that states that the sum of voltages around a loop must be zero. To get 1.6 mA at 8 V we need a 5 kΩ resistor, we’ll use the more common 5600 Ω device. At our peak voltage of 13.4 V, we’ll have 2.2 mA of current through the optocoupler’s LED, well below the 30 mA maximum value the device can handle. 

If the optocoupler’s output signal is tied to the input line of a microcontroller, a simple software missing pulse detector can be used to detect when the doorbell button is closed, see the sample below. In this example we check the value of the optocoupler’s output once each ms for one 60 Hz cycle, or one 17 ms period. If it is ever zero the button is open.

Physical Implementation

The complete schematic, with component values, power ratings, and tolerances, is shown below. Component tolerance describes the range of possible actual values of a component as a percentage of their ideal value. If our 5600 Ω resistor has a 10% tolerance, then a real device may have a resistance value as low as 5040 and as high as 6160, with the actual value being somewhere between these extremes. It is important to take these minimum and maximum values into consideration during a design.

Our design is sensitive to the value of R3, the 5600 Ω resistor. For this reason we chose a device with a 1% tolerance. This costs a bit more, but in this case it was important. Also note that we chose a 3W resistor for R1 to ensure we don’t have a catastrophic failure, a fire!

The printed circuit board layout for the above design is shown below. The pads on the far left are for TB1 which is a connector where the two wires from the doorbell button are connected. Notice R2 in the lower right hand corner of the PCB. It is the 680 Ω output resistor and is a normal sized surface mount resistor. Compare this to the size of R1 which is the 220 Ω 3 W resistor, quite large in comparison.

This circuit results in a simple layout that doesn’t require a 4-layer PCB. However, to simplify connections to other myDoorbell modules, a 4-layer technology was used. No routing on the bottom of the board was required. The inner layers are used for ground and 3.3 V and are brought to the top layer using the three visible vias.

When integrated into the final system, small changes were made to optimize the overall layout. In the above photo of the myDoorbell button detection module, you’ll notice that the two smaller resistors and the diode have been move to slightly different locations. The final system contains two of these modules, one for the front door and the other for the rear door.

Outcomes and Artifacts

This post describes a simple circuit and associated software that meets the requirements of keeping the doorbell lamp functional and detecting when the button is pressed. There are likely many alternative techniques for meeting these requirements, but one worth considering is to use an AC line monitor chip such as the MID400 which is intended to raise a signal if the power line voltage is interrupted. In our scenario it would raise a signal if the AC voltage across the doorbell button was absent, or in other words, the button is pressed. This unit costs slightly more than the circuit described above, but would eliminate the need for the external diode and the missing pulse detector software. The output could be tied to a microcontroller interrupt line making the system more responsive, reliable, and perhaps simpler.

The Eagle schematic and PCB files are available from the myDoorbell repository at

Basics to Remember

The power dissipated by a resistor is equal to the product of the voltage across it and the current through it, P = VI. However, we often don’t know the voltage across a resistor, but rather know the resistance value and the current through it. In this case a simple manipulation of Ohm’s Law yields a solution, P = I2R.

The sum of voltages around a circuit loop must be zero. This fact is known as Kirchhoff’s Voltage Law. It is useful for circuit analysis and as used in this post to determine the proper circuit element values to meet requirements.

myDoorbell: The Power Supply


In my previous post, I described the nine modules that make up myDoorbell. While we could begin our discussion with any one of the nine modules, the one all others are dependent on is the power supply. What the power supply is intended to do is convert the source characteristics we have, to the supply characteristics we need. In other words, it needs to convert the 16 volt (V) alternating current (AC) available in the doorbell-wiring box to a direct current (DC) voltage appropriate for our use.

What myDoorbell Needs

Reviewing the datasheets of components, likely to fulfill the function of each of the other eight modules, led me to believe that seven of the eight modules need a 3.3 volt (V) supply. The Audio Amplifier module is the exception.

Audio amplifiers are designed to take small signal inputs and accurately reproduce them with additional power. Like the other modules, the amplifier is powered by a DC source. Since power is equal to the product of voltage and current, it is possible to increase the power of the output signal by increasing its voltage, current or both. It is impractical to use the 3.3 V DC source for the audio amplifier given that we have an upper bound on the available current of just over 1 ampere (A). This combination would result in a 3.3 watt (W) (3.3 V * 1 A) maximum output power. This is insufficient power to drive a speaker at the volume necessary for a doorbell. The better option is to convert the 16 V AC source to the highest voltage DC source conveniently available.

So myDoorbell needs are simple, a 3.3 V DC supply for the digital components and the highest practical DC voltage available for the Audio Amplifier module.

Basic DC Power Supply

A simple DC power supply is illustrated below. The AC input is connected to the primary terminals on the left of  transformer, TR1. This AC input is a sine wave that swings from a negative to a positive peak with a frequency in the U.S. of 60 cycles per second, or 60 Hz. AC voltages are typically described in terms of their root-mean-squared or rms values. Their peak and rms values are related by, Vrms = 0.707 * Vpeak. In the U.S. a common input voltage is 120 Vrms.

In a typical application, the transformers job is to reduce the input voltage to a voltage just slightly above the desired power supply output voltage. For example, if the desired output voltage is 3.3 V DC, a transformer that transforms 120 Vrms to 5 Vrms may be appropriate. A typical transformer works by having two electrically insulated coils of wire wrapped around a common ferrite core. The coil connected to the input is called the primary, while the other is called the secondary. The ratio of turns on the secondary to primary coils determines how the secondary voltage compares to the primary voltage. For the above example, the primary coil should have 120 V / 5 V = 24 times as many turns as the secondary.

The full-wave bridge rectifier, B1, inverts the negative half-cycles of the transformers output voltage and passes both half-cycles to the output of the rectifier. While this output is DC, the waveform has significant ripple, varying from zero to the positive peak at 120 Hz. The ripple is reduced by capacitor C1 which brings the voltage across C1 to nearly the peak value of the rectifiers output. IC1 is an integrated linear voltage regulator that typically takes a voltage input higher than the desired output voltage and locks its output to the target voltage. Finally, C2 reduces the remaining ripple to tolerable levels.

Continuing with our example, the output of the transformer is 5 Vrms. The full-wave bridge rectifier creates a 120 Hz DC voltage that varies from 0 V to 5 V / 0.707 or 7.07 V. Capacitor C1 reduces the ripple and presents a fairly constant 7.07 V DC input to the voltage regulator. The voltage regulator locks its output to the desired 3.3 V level and most of the remaining ripple is removed by capacitor, C2.

myDoorbell Power Supply

It took me three attempts to find a satisfactory design for the myDoorbell power supply. Recall that the goal is a DC power supply that can power seven of the eight modules at 3.3 V DC and the amplifier with the highest voltage conveniently available. The seven digital modules consume a total of approximately 300 mA or 0.3 A of current at 3.3 V. To provide a margin of safety we will design the power supply to provide 500 mA. The DC voltage at the input of the voltage regulator is equal to 16 Vrms / 0.707 or 22.6 V DC. This will be used for the Audio Amplifier module.

Attempt 1 – Linear Voltage Regulators

The most straightforward DC power supply design for myDoorbell follows the design pattern illustrated earlier. In this simple design the voltage regulator is a simple three pin linear regulator. However, through sad experience this approach doesn’t work in this application because of the large difference between the 22.6 V regulator input voltage and the desired 3.3 V DC power supply output. In our earlier example, the designer was free to pick a transformer that reduced the input supply voltage to a reasonable level. In the myDoorbell world we are stuck with the doorbell transformer that reduces the 120 Vrms line voltage to the available 16 Vrms. This results in the 22.6 V regulator input voltage and the issues using the linear regulator.

The power dissipated by the linear voltage regulator is equal to the product of the voltage across the device and the current through it.

Pregulator = Vregulator * Iregulator
Pregulator = (Vin – Vout) * Iregulator
Pregulator = (22.6 V – 3.3 V) * 0.5 A
Pregulator = 19.3 V * 0.5 A
Pregulator = 9.6 W

This is a significant amount of power that is presented as heat. Without a significant metal heatsink being thermally attached to the voltage regulator it will consume itself. In fact my first design did just that. I was taught that digital electronic systems work because of magic smoke contained in them. When I naively built and tested this design the device overheated, the magic smoke escaped, and the device no longer functioned. While this power supply design is not feasible for myDoorbell, it might effectively test your smoke detectors.

Attempt 2 – DC to DC Converter

After licking my wounds of defeat I came across a device that I thought would fit my needs perfectly, a DC to DC converter. This device is essentially a small power supply integrated into a single package. This device accepted a broad range of input voltages and output 3.3 V at up to 500 mA, a perfect fit.

However, the particular device I chose had a “feature” that caught my eye as a positive thing, but ended up being a show stopper. The grounds on the input and output of the chosen device were isolated. This sounds like a good thing, but after prototyping myDoorbell and debugging for a significant amount of time, a serious design flaw was discovered.

Recall that the audio amplifier will operate from the highest DC voltage conveniently available to us. Well the highest voltage available is the DC voltage just before the DC to DC converter. The voltage available at that location is 22.6 V and is ideal for our audio amplifier. However, the digital electronics will be operating on the opposite side of the DC to DC converter. This includes the MP3 to audio converter that outputs the low voltage audio signal to be amplified. Voltage is an across variable or the potential across two points, typically the signal and a reference ground. In this particular design the MP3 decoder and the audio amplifier share the signal line, but not a common reference. If these grounds are connected, the DC to DC converter does not function properly, if they are not connected, the audio subsystem does not work. Another failure!

After making another design choice, I discovered that there are DC to DC converters that are non-isolated. While this would have worked, a better design in terms of cost exists.

Attempt 3 – Switching Voltage Regulators

Switching voltage regulators are an alternative to the linear device discussed above. A very simplistic description of how this device operates goes something like this. The device checks the voltage across the capacitor on its output and if it is below the target voltage, the device charges the capacitor. If the voltage on the capacitor is at or slightly above the desired voltage, the device allows the capacitor to discharge. This switching occurs thousands of time per second resulting in small swings between minimum and maximum values. This regulator dissipates far less power and can easily function without a heatsink. The tradeoff is that this device requires a few more components as shown in the following figure taken from the Texas Instruments TL2575 datasheet.

According to the datasheet capacitor Cin stabilizes the regulator, Cout reduces ripple on the output, while diode, D1, and inductor (coil), L1, reduce high frequency noise. The design, shown below, comes from the datasheet with some slight modifications. According to the datasheet, the size of the inductor depends on the output voltage and current characteristics. Referring to the graph included in the datasheet, we chose a 0.001 Henry, 1 mH, inductor. My complete and successful design is illustrated below. 

The light emitting diode (LED) and resistor R1 were added to yield a simple power on indicator. The transformer, TR1, is the doorbell transformer and is shown solely for clarity and is not included in the final design. The voltage available after the full-wave bridge rectifier is approximately 22.6 V of smoothed (filtered) DC, perfect for our audio amplifier. The final output is our desired 3.3 V regulated and smooth DC supply, perfect for the remaining digital components making up the system.

Physical Implementation

This section describes the design process used to implement the above schematic in a surface mount printed circuit board (PCB). We begin by identifying the components that are required, see below.

While I used the Eagle computer aided design (CAD) tool to input the above schematic and realize the PCB output files, any reasonable tool will do. Most PCB tools have thousands of predefined library components, but I prefer to build my own library parts because I suffer from the dreaded, not invented here syndrome.

I will illustrate my process for building these library components for the full-wave bridge rectifier, but the same process would be followed for all components used. From the rectifier datasheet we can extract the “suggested pad layout”. If the datasheet for a particular device does not include this, then I select another vendor’s product, that simple! The pad layout is the copper pattern that will be left on the PCB where this device is electrically and mechanically connected using solder. The suggested pad layout for the full-wave bridge rectifier, DF206ST-G, is shown below.

This pattern is added to the library of components and associated with the components schematic drawing. This process is completed for all necessary components.

The schematic is built by placing the selected components and wiring them as illustrated. In Eagle you then convert this to a PCB that results in each component being placed on the PCB with lines connecting the appropriate signal pins. The components are moved into appropriate positions by the designer and the lines are replaced with copper interconnects either automatically or by hand.

Printed circuit boards are made up of layers of conductive material, such as copper, separated by layers of insulation. Layers can be connected through a via. The top and bottom layers are typically covered with a material that doesn’t easily adhere to solder. These layers have openings where solder and components are to be connected to the copper traces.

For myDoorbell I decided to use a 4-layer PCB process. This process has a layer of copper on the top and another on the bottom and two internal layers. The top and bottom layers are used to route interconnections. One of the internal layers is used to distribute 3.3 V to the entire system. The second internal layer is tied to ground and distributed throughout the design. These internal layers are often called planes. While myDoorbell is reasonably simple and might have been possible with a two layer design, having a ground and power plane results in a safe and simplified design. The top view of the resulting power supply PCB is shown below.

Those items represented in gray indicate labels and component outlines that will be visible on the completed board. The red areas represent the copper pads and interconnects on the top layer of the board. This board does not have any copper on the bottom layer. The green circles indicate where a via is used to connect the top copper to either the ground or 3.3 V planes. The dotted lines around the board represent the 3.3 V and ground planes.

In the upper left hand corner of the board there is a component we have not yet discussed. It is a simple connector where the two wires from the doorbell transformer are connected to the power supply. These feed directly into the full-wave bridge rectifier to the right. The positive output terminal of the rectifier is connected to the positive terminals of the capacitors, C1, C2, and C4, as well as the input of the regulator. The negative side of the rectifier is connected to ground through the via to its upper right. All other devices connected to ground do so through a via to the ground plane.

Due to the laws of physics, each wire is also an inductor and as such resit changes in current flow. The longer the wire, the more inductance it will have. For this reason it is good practice to minimize the length of wires connecting components, especially those that are high speed such as the switching regulator. You’ll notice that C1, C3, and Z1 are close to the regulator. One reason internal ground and power planes are useful is because they facilitate the close connection of components, reducing wire length, and inductance.

The large copper area in the upper right corner of the board connected to the ground plane through 8 via connections is where the regulator is physically connected to the board. The heat from the regulator flows through its body, onto this copper pad, and into the ground plane. This acts as a heatsink pulling the heat away from the device.

Note that the positive terminal of C3 connects to the 3.3 V internal plane through three via connections. Later this same 3.3 V plane will be connected to the rest of the myDoorbell circuit. The positive side of the rectifier component is the source of the 22.6 V that will be used by the audio amplifier.

The resulting PCB measures 59mm in length and is 32mm wide. For testing purposes it was increased in size to allow for the inclusion of a set of header pins for easy insertion into a prototyping board. This breakout board is illustrated below. The tested board delivered 3.3 V at 400 mA and 22.6 V at nearly 1 A. This perfectly matches the needs of myDoorbell. Success at last!

Outcomes and Artifacts

Outcomes include lots of learning, a useful DC power supply design, and a working version implemented as a 4-layer PCB with surface mount components. The circuit is capable of inputs up to 20 Vrms resulting in a high voltage output of just over 28 V DC. By simply replacing the regulator with a product family substitute, the low voltage output can be changed to 5 V, 12 V, or 15 V. The schematic, PCB layout, and bill of materials can be acquired from github.

Basics to Remember

The relationship between peak and rms voltages is described by, Vrms = 0.707 * Vpeak.

Ohms Law states that voltage (V) is equal to the product of current (I) and resistance (R). voltage is measured in volts (V), current is measured in amperes (A) and resistance is measured in ohms (Ω).

Resistors (R) are measured in ohms (Ω), capacitors (C) are measured in farads (F), and inductors (L) are measured in henrys (H).

Due to the laws of physics, each wire is also an inductor and as such resit changes in current flow. The longer the wire, the more inductance it will have. For this reason it is good practice to minimize the length of wires connecting components, especially those that are high speed.

Component datasheets are our friends and we should get use to reading them, understanding them, and referring back to them often. They look long and complex, but you’ll get use to them.

Datasheets often have a “Typical Application” section that illustrates how the component can be used. This schematic can often be used as is or with minor modifications for your application.

LEDs can only handle so much current before their magic smoke escapes. The more current that flows through them, the brighter they are, within limits. 5 – 10 mA of current seems about right for many applications. The resistor in series with a LED is intended to limit the current. If you assume the voltage drop across a LED is 0 V, then the entire potential is across the resistor. Ohms Law states that the voltage is equal to the product of current and resistance, so the resistance is equal to the voltage divided by the current. In our example power supply, the voltage across the resistor is 3.3 V, so to limit the current to 5 mA we need a resistor of 3.3 V / 0.005 A = 660 Ω. Since resistors come in standard values we’ll use the closest standard value of 680 Ω.

Indie Educational Technology


Last week I spent some time at Davidson College discussing Personal APIs and Indie Educational Technology with faculty, students, and staff from several other institutions of higher education and commercial entities, Known and Reclaim Hosting, that facilitate this work. This was a fantastic gathering of bright people and I can’t wait to be with them again. Thanks to Kristen Eshleman for getting us together, to Ben Werdmuller and Erin Richey for their instruction, to Audrey Watters for her insightful description of indie, and to Tim Owens, Jim Groom, Kin LanePhil Windley and Troy Martin for always making me think better. After returning to my day job I found myself asking the question, what is “indie educational technology”?

According to CNN “If it’s cool, creative and different, it’s indie” and the Urban Dictionary defines indie as, “an obscure form of rock [music] which you only learn about from someone slightly more hip than yourself.” I had to travel to North Carolina to have people, more hip than myself, educate me! I thank them and hope they continue to help me progress.

While I’m pretty sure the term “indie” in this context meant “independent of vendors and personal”, for my purposes I’m going to define indie educational technology as information technology that is cool, creative and different used to enhance the educational process.

Indie technology benefits both students and educational institutions. Students have a greater sense of ownership and motivation when they (a) control their personal information and (b) are able to interact with institutions with both institutionally provided applications and alternative systems (McCombs, 1997). Institutions benefit by having alternative application-hosting options and are not unnecessarily burdened by housing personal student information with its associated liability.

For example, let’s consider a traditional, non-indie, university registration system. One or more centralized systems contain university information about courses, classrooms, and instructors. In addition to this information, these systems contain personal student information that students are required to submit to participate in the registration process. To register for classes, students present user credentials to the university provided registration system, register for classes, and end their interaction. In this model the university retains personal student information, insists that students use the university provided system, and refuses to make alternative systems possible or feasible.

Consider an alternative, the indie approach. Like the non-indie system described above, one or more centralized systems contain university information about courses, classrooms, and instructors. However, personal information is not retained in this system. A student’s personal information is housed in a student-controlled system. Students authorize the university’s system to access necessary information. In this case students register for classes by presenting credentials to a registration application of their choice. This registration system requests and receives authorization from the university and the student to acquire university and personal student information, respectively. They register for classes and end their interaction. In this model the registration application disposes of personal and university information it was exposed to, while the university system retains the information necessary to indicate successful registration. In this scenario students may choose to use the university provided registration tool or alternative systems. In addition, the university does not house personal information or bear the associated liability. That’s cool, that’s indie!

So what makes this technology cooler, more creative, and different from what currently exists? Let me suggest that it is because indie technology will have several characteristics:

  • Personal API Enabled
  • Substitutable
  • Open Source
  • Modular
  • API-Based
  • Event-Driven

Let me elaborate on each.

Personal API Enabled

A personal API (PAPI) is an interface to personal information and resources. The resource owner protects these resources through explicit authorization. There are at least three key benefits of developing and using a PAPI:

  1. A PAPI changes the expectations of users. They develop a sense of ownership of their information and resources and begin to expect institutions to respect their rights and privacy. The use of a PAPI at an institution of higher education yields a perfect opportunity to educate students about these issues and help them understand what they should expect from other vendors and providers. They benefit from the ability to disassociate from institutions by simply revoking authorization to their data.
  2. A PAPI eliminates the need for a single university or vendor-provided application that all users must interact with. Users interact with their PAPI using applications of their choice. Institutional systems request permission to access personal information through the PAPI to perform needed functions. Institutions may provide applications for users, but the PAPI facilitates the creation of alternatives.
  3. A PAPI frees institutional technology modules from having to unnecessarily hold personal information. Institutional systems request needed personal information through the PAPI to perform their functions. Institutions should find this attractive because they will house less personal information, reducing their liability.

Note that giving people a personal API and letting them control their data, doesn’t mean that they get to control the university’s data. A PAPI lets people control the data that is theirs. For example, their phone number is their data. Their grades, on the other hand belong to the University. In addition, if students exercise their right to not authorize university access to needed personal information, the university is not obligated to fulfill the desired student request. University policy and process must still be followed.

The institutional complement to the PAPI is what we call the University API (UAPI). Through the UAPI an institution protects its resources through explicit authorization. In our example indie class registration system, the UAPI would make course, classroom, and instructor information available to the student chosen registration application. In addition, the UAPI would record the necessary registration outcomes.


Substitutability is the ability to use alternative systems or services to accomplish specific functions and move from one platform to another with ease and at little expense. This is applicable to both users and institutions.

Substitutability benefits users by allowing them to move their systems and services to alternative providers. They are also free to choose alternative applications to perform functions of interest. Institutions should facilitate both by pursuing strategies that allow authorized access to institutional information and consume necessary personal information through a PAPI respecting the user’s expectations of privacy.

Institutions benefit as well. Their systems can be operated on multiple platforms and through the use of technologies such as the UAPI and the PAPI, alternative systems can be used to accomplish institutional functions. If institutional systems only work properly when hosted at a single provider or moving them is onerous, institutions leave themselves vulnerable and open to the policies and practices of that provider. The inability to easily substitute one provider for another brings us back to our current state of affairs.

Open Source

Created systems and services should be freely available to others. First, this is what the cool kids do – indie. Second, by making them and API definitions freely available, others are more likely to adopt the technologies. Wide adoption results in many smart, hip people working on the same problems, resulting in better solutions. Licensing them appropriately protects our ability to use the things we develop.


Modularity facilitates and drives an increased pace of innovation. Each module should deliver a small set of functions within a single bounded context as defined in the domain-driven design process. While these modules can be created using various techniques, at Brigham Young University (BYU) we will be defining them as microservices. These microservices will result in stand-alone modules that are easily understood by developers and will encourage extremely loose-coupling, facilitating a building block mentality to building systems. This approach will drive innovation in the core processes of BYU. 


Each module will have an API that enables communication to and from the module. The API simplifies the use of the module and abstracts away the internal implementation. This abstraction permits changing the underlying implementation while protecting systems that rely on the module’s API. 


While not strictly necessary, event-driven architectures are more efficient and absolutely cooler than polling-based systems. I think this alone makes event-driven, modular design a part of indie technology!

In a polling-based system you only become aware of changes when you ask if changes have been made. For example, in a registration system you determine how many students have registered for a particular class by asking (polling) the system. In an event-driven architecture, each time a student registers for a class an event reflecting this activity is posted to interested listeners. This results in more efficient communication and more timely responses to change. What could be more indie?

Now What

At Brigham Young University we intend on building many, if not all, of our core academic systems and services using modules with the above characteristics. The result will be a collection of modules that perform core functions of the institution, but are likely usable by others.

I hope that we can find ways of including others outside of the BYU community in the creation of our functional modules, systems, and services. Including others will make our work better, but more importantly will result in definitions and implementations that are more generic, enabling others to use them more easily. Each module, system, and service will have the characteristics outlined above making their use elsewhere practical and possible.

Finally, I hope we can all find a way to meet regularly to showcase our attempts, failures, and successes. We, at BYU, are open to conferences, workshops, or other venues where we can all continue this discussion.

myDoorbell: High Level Design


In my previous post I described the resources available in the wiring box where myDoorbell will be installed. As illustrated in the following figure, the available resources consist of a 16 Volt AC source and a connection to a doorbell button with an integrated lamp.

When the button is pressed, approximately 1 Ampere of current flows through the circuit. This current at 16 Volts AC yields 16 Watts of available power (16 Volts * 1 Ampere). This is sufficient for anything I am envisioning. For a more thorough, yet simple, explanation of Ohm’s Law click here.

Features and Hindsight

As pointed out in my first post on this subject, myDoorbell will have several unique characteristics or features:

  • Play ringtones uploaded by the user to celebrate seasons, holidays, birthdays, etc.
  • Record the time and date of each ring
  • Be configurable
  • Send a text message indicating a ring, if configured to do so
  • Be silent if configured not to make noise when babies are sleeping, pets shouldn’t be disturbed, or the owner just doesn’t want to know visitors are present
  • Access other Web resources such as APIs, webhooks, etc. 

As the saying goes, hindsight is 20/20. If I were designing myDoorbell all over again, I actually am, the next thing I would do is design the API that would describe the HTTP resources, methods, and error codes used to implement the above features and behaviors. However, when I began this adventure I didn’t know much about APIs, HTTP, and related technologies. Recall that this lack of knowledge was precisely why I started this adventure.

I will proceed in roughly the order I actually took, but want to encourage any readers creating hardware or software systems that they should design the API first. Since software is eating the world it is clear that any real system will contain software, and I believe that all such systems should have an API. Creating the API first will result in a better product and will reduce the risk of cresting hardware and software components that in the end are unnecessary.

Necessary Components 

Several hardware and software components are necessary to implement the characteristics and features listed above:

  • myDoorbell needs Internet connectivity to facilitate the uploading of ringtones, to enable the calling of other APIs or to raise events, and allow the acquisition of configuration information and updates. Since there is no wired network connection in the doorbell wiring box, this connectivity will be provided by a WiFi module. 
  • A microcontroller is needed to interact with the WiFi module, provide a compute platform for the web server implementing the myDoorbell API, interface with a nonvolatile memory, and enable the detection of the state of the doorbell button. 
  • A software module is needed that time slices between detecting the state of the doorbell button and dealing with incoming network traffic. It must also copy incoming ringtone data to the nonvolatile memory. Finally, this module must implement outgoing requests and the raising of events.
  • A simple hardware module is needed to provide doorbell button state information to the processor.
  • A nonvolatile memory is needed to store ringtones and configuration data. This memory needs to be writable by one microcontroller and readable by another, two ported.
  • A second microcontroller is needed to copy ringtone data from the nonvolatile memory to the audio system. 
  • An audio subsystem is necessary that converts mp3 encoded music to audio and amplifies the resulting audio to a sufficient amplitude to drive a speaker to the required volume.
  • A power supply is needed to convert the 16 Volt AC to a 3.3 – 5 Volt DC source for the digital electronics and a higher DC source for the audio amplifier. 

The following figure is a block diagram illustrating the hardware components listed above. Note that there are two modules for detecting the doorbell button state because most commercially available doorbells have the capability of ringing for both a front and rear door.

There are of course many ways to design any system, and I am not arguing that this is the best or even a reasonable design. In addition, as technology changes so do the choices and possible optimizations. My intent was to learn, and I learned a lot. In my next post I will describe the power supply module. This seems simple, but hang on and keep your arms and hands in the ride at all times!