# Introduction

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 Ω.

# Introduction

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

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

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.

## API-Based

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.

## Event-Driven

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.

# Introduction

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!

# Introduction

In my previous post I declared my intent to refresh my technical skills through the development of an amazing doorbell, myDoorbell. In this post I describe a doorbell system found in a typical U.S. residence and discuss how this influenced the design of myDoorbell.

# Typical Doorbell System

A typical doorbell system consists of several components: a doorbell button, a ringer mechanism / solenoid, and a doorbell transformer. These components are connected as illustrated in the following schematic.

When the doorbell button is pressed, AC flows through the solenoid causing it to strike a metallic bar tuned to create the expected “ding” sound. When the current is removed the solenoid is pulled back quickly by a spring, causing it to strike a second bar resulting in the anticipated “dong” sound. Many doorbell buttons have associated lamps to facilitate finding them in the dark. Like the button, the lamp also closes the circuit and energizes the solenoid. However, the resistance of the bulb limits the resulting current to a level that does not cause the solenoid to strike the metal chime.

In a sample system, acquired from a local home improvement store, the current through the solenoid was approximately 1 A when the button was pressed. When the button was not pressed the standby current was approximately 52 mA. A simple application of Ohm’s Law, 16V AC / 52mA, suggests that the resistance of the lamp is approximately 308 Ohms. When the lamp burns out, they always do, the standby current is reduced to zero.

One design decision I made early on was to enable myDoorbell to function with the existing doorbell button and transformer. In other words, myDoorbell would replace just the ringer portion of an existing system. In a common installation a pair  of wires from the button and a pair of wires from the transformer are brought to a wiring box where the ringer is installed. This is illustrated in the figure below.

The resources available in the wiring box are the connections to the push button, that requires 16V AC to power the lamp, and 16V AC. In my next post I’ll begin describing the design of myDoorbell based on the identified constraints and resources.