A dimmer is an electronic device that controls alternate voltage applied to a lamp through delivering a selected portion of the mains sinusoid. Engineer, designing a dimmer needs to estimate how big this portion should be to get a desired luminance level. This article uses a model of incandescent lamp, tungsten resistivity, and human eye spectral efficiency to derive dependency of produced luminous flux over the voltage, gives a simple analytical function that describes this dependency with good accuracy (±2% comparing to the model).

Download PDF version of this article

Structured Abstract

Definitions

Process of controlling some output value (such as voltage U or luminous flux L) we will denote as a control function , defined on the control parameter :

(1)

Each of  monotonously increase on the defined range. Control functions defined on a different (other than ) argument we will denote in this article as .

Commonly used are linear () and logarithmic () control functions. To implement a desired control function , we needs to know what is  dependency. 
The following chapters give an attempt to derive  using a model suggested in (Agraval 1996).

Incandescent Lamp Model

An incandescent lamp is characterized with few nominal values: P_N – power consumption, U_N – nominal voltage, L_N – nominal luminous flux, produced by the lamp at nominal voltage. The flux is produced by filament, incandesced to nominal working temperature T_N.
When lower voltage U<U_N is applied, operating temperature T of filament is lower T_N and therefore it produces less luminosity L.

Filament Resistance

Power, consumed by a lamp, is expressed with Ohm low:

(2)

where  defines dependency of filament resistance over the temperature relatively to its nominal resistance R_N, which can be evaluated via P_N and U_N:

(3)

Dependency  for tungsten is not linear in the working range of temperatures (1000-2500K). For this model we will use polynomial approximation of tungsten resistance ρ, [Harang 2003]:

(4)

 can be expressed via  as the following:

(5)

Filament Temperature

During operation, filament radiates electromagnetic energy and dissipates heat via conduction and convection. To estimate radiation, filament is modeled [Agraval 1996] as a simple non-ideal blackbody that obeys Plank’s radiation law:

(6)

where  is power radiated between wavelength  and ,  - tungsten emittance, and A is filament area. The total power emitted over all wavelengths is:

(7)

where σ is the Stefan-Boltzman constant and  is average emittance over all wavelengths, which is approximated as a second order polynomial (Harang 2003):

(8)

In a steady-state operation, power applied to the lamp is in balance with power radiated and dissipated to outside ambient. Dissipation has two constituents – conduction and convection. Agraval in [Agraval 1996] has suggested a reasonable way of accounting dissipation as a factor of input power:

(9)

Solving (8) for P:

(10)

Substituting left side of (10) with right side of (2):

(11)

Using (11), we may derive :

(12)

Figure 1 illustrates dependency

Figure 1. Dependency of T on fraction of applied voltage ξ_U for different T_N

Luminance

Not all power radiated by filament has its effect on luminous flux. Some of the energy is absorbed by bulb glass and dissipated as heat. Although, this absorption depends on λ, we will simplify this absorption to a constant factor η<1.

Major part of the emitted energy is not visible to human eye. This is described as spectral efficiency function S(λ), approximated as the following [Agraval 1996]:

(13)

Thus, total luminous flux produced by a lamp can be defined as:

(14)

where

(15)

Thereby, control function  can be expressed as a function of T:

(16)

For working range of temperatures and visible area, emissivity є(λ,T) can be approximated as the following [Larrabee 1957]:

(17)

where T is in °K and λ in nm. Substituting (17) in (16) and integrating numerically (16) we get dependency, shown on Figure 2:

Figure 2. Dependency ξ_L(T) for different T_N

Solving Luminance vs. Voltage

Using T as a parametric variable, we may numerically compute (11), (15) and graphically solve dependency ξ_L(ξ_U), as shown on Figure 3:

Figure 3. Dependency ξ_L(ξ_U) for different T_N

As Figure 3 indicates, ξ_L(ξ_U) is affected by a design factor – nominal temperature T_N.

Approximation

Figure 4. Dependency ξ_L(ξ_U³)

As it appears (see Figure 4), dependency ξ_L(ξ_U³) looks quite linear for ξ_U³>0.2 and has some higher-order dependency for ξ_U³<0.2. Therefore we will try approximating ξ_L(ξ_U) as two polynoms:

(18)

Value ξ_Lat x=1 is equal to 1 by nature of ξ, therefore c can be expressed via k:

(19)

To solve a and x₀ we will require continuality of  and its derived function , this gives us two equations with three unknowns:

(20)

Solving (20) for a and x₀ we get them expressed via k:

(21)

Thereby,  depends on a single constant k, which is then wiggled around to find a value giving lowest RMS deviation . Table 1 lists selected values for few most common nominal temperatures T_N, Figure 5 illustrates this dependency, and Figure 6 shows modeled curves and values, approximated with (20).

Table 1. k values for some T_N

Figure 5. k variations over T_N

Figure 6. Modeled curves and approximated values (marks)

Since designer of a dimmer may not exactly know nominal temperature of the dimmed lamp, kcan be selected for an average nominal temperature. Suggested value k=1.05 gives ±2% error (against the model) for T_N in range 2800-3100 °K. For this k, equation (20) becomes practically concrete:

(22)

Sine Wave Dimmer

A sine wave dimmer implemented with pulse-width modulation controls applied voltage with a cycle duty, which we will denote as control function ξ_t. Modulation frequency is usually chosen much higher than mains frequency. Therefore, RMS of output voltage is proportional to cycle duty, and control function ξ_U as simple as:

(23)

To make ξ_L(p), linear on parameter p, function ξ_t(p) should be defined as the following:

(24)

Applying (24) to equation (22) we get

(25)

Phase Control Dimmer

When implementing an AC dimmer based on phase control technique, one needs to tabulate cycle duty values ti as a function of desired luminance level pi. 
Following the same approach, we introduce control function ξ_t:

(26)

where t is cycle duty (time when the switch is on) and tM is the mains half period, and f is the mains frequency. Average power  applied to the lamp, can be evaluated as the following:

(27)

where UA is voltage amplitude. Integrating (27) we can define ξ_P as the following

(28)

Considering that , and substituting (28) to (22) we may estimate .

Figure 7. Dimmer control functions ξ_L and ξ_U

Applying approach used in (24) function ξ_t(p) is defined as following:

(29)

Although, reverse function of (28) is not solvable analytically, it can be solved numerically.

Conclusions

As a result of numerical modeling, the following approximation functions are suggested:

• Estimation of produced luminous flux over the voltage:

L = L0 * ((U/U0 < 0.575) ? 1.369 * (U/U0) ^ 4 : (1.05 * (U/U0) ^ 3 - 0.05);

• Tabulation of cycle duty over the control parameter p

t = (p < 0.1496) ? (0.925 * (p) ^ -4) : (0.984 * (p + 0.05) ^ -3);

References

Agraval D.C., Leff H.S., Monon V.J. (1996)
"Efficiency and efficacy of incandescent lamps"
American Journal of Physics, May 1996, Volume 64, Issue 5, pp. 649-654
http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=AJPIAS000064000005000649000001&idtype=cvips&gifs=yes

Harang O., Kosch M. J. (2003) "Absolute Optical Calibration Using a Simple Tungsten
Bulb"
Sodankylä Geophysical Observatory Publications, 2003, pp. 92:121-123
http://spaceweb.oulu.fi/28AM/proc_papers/27_harang_et_al_calibration_with_tungsten_bulb.pdf

Larrabee R.D. (1957) "The spectral emissivity and optical properties of tungsten"

Research Laboratory Of Electronics, Massachusetts Institute of Technology
http://dspace.mit.edu/bitstream/1721.1/4755/1/RLE-TR-328-04734719.pdf

I would like to discuss with you my ideas on new programming language for embedded applications, denoted further as e#. I value your time and therefore in this post I am trying to be short and precise as much as possible.

Table of Contents

My goals are:

• Share ideas and get opinions from experienced people;
• Stress the idea with criticism;
• Find associates for developing the language;
• Design a language that would help other developers to follow OOD paradigm and give them better ability for reusing once implemented objects.

The new language should (is expected to):

• bring a disciplined approach to the "programming in a small" field;
• suit for most of MCU platforms and experimental processors;
• provide a good replacement for different ASM-associated languages ;
• give a tool for automated application testing on a simulator;
• provide better porting/multitargeting capabilities;
• reduce impact caused by moving to another hardware platform;
• benefit to all parties involved in developing embedded applications.

Other languages considered

JAL, NASM, TAL, HAL, ISDL, VHDL

Definitions

Device language – its statements, being translated, are actually executed by the device(s)
Tool language – its statements are executed by a development tool on a host computer.
Builder – a development tool that controls all stages of a build process, e.g. compilation, linking, etc.

History Excursus

The way assemblers look now is rather tradition that comes from 40-s/50-s of the last century. The earliest instruction set definition for a digital computer I have found on the network (code for A.R.C)¹includes binary form (example) and a “human readable” semantic expressed in math symbolic extended with arrows for register injection. This kind of “human readable” semantic is still in use.

Coding with this kind of “language” was difficult and error prone. Although, the theory of computing languages already existed at that time, computers were not yet powerful enough to run a compiler. Thus scientists were searching for more convenient way to program a computer. As results of these researches “X-1 assembly system” was published in 1956 and “Symbolic Assembler” was defined in the late 1950s and published in 1962(?), EDSSAC assembly language (reference and the first programmed game).
It seems, real breakthrough has happened with NYAP Autocode for IBM 704 developed at NY University, which, I guess, then become Autocoder for IBM 1401 ??“ perhaps, the first assembler in the industry.

Assembler Syntax

Although I have not done fundamental research on instruction sets of first computers, it seems that one approach (introduced by ?) has become dominating over the others. With this approach every instruction has an operation code at most significant bits while remaining bits are used to keep the operand(s). Thus an instruction can be logically divided onto fields: <opcode>[<operand>??¦]. This approach led to simplification of hardware design and presumably has influence on instruction set mnemonics provided with the computers. Making a language from instruction set mnemonics seems to be a very logical step ??“ the language reference was available, published and recognized by the community

Since that time the core language principles are remaining unchanged and spread over all families and generations of processors and microcontrollers. There are only few exceptions from this rule, such as ADI assembler¹ which uses ‘=’ operator for register injection or AT&T syntax style with its variation for operands.

To do

Research on history of macro language

Links on Assembler History

Although macro-assembler in most cases is referred as a single language, it worth to mention that it actually consists of two languages – ASM part and macro part. This is especially noticeable when switching from one family to another – macro part remains the same while ASM part is noticeably different due to difference in the instruction sets. Besides these two languages, there are also some other languages involved in process of developing an ASM application.
Table 1 gives list of identified programming languages (PL), their inputs and productions:

In some cases these languages provide overlapping capabilities, such as preprocessor’s #define vs macro’s equ and macro’s .org vs linker’s section start=.
From this set of languages only ASM is a “real” device language, whose statements will be actually executed by the device(s). The other languages are tool languages, executed by the development tools.
Also there is a pseudo language used for expressing statement semantics (A <- B – A). Such pseudo language is necessary, because the mnemonics themselves are not descriptive enough (not “human readable”). Having just a mnemonic it is hard to say what the action it implies and what objects it affects. Furthermore, similar mnemonics given by different vendors may imply different semantics, which make it even more complicated.

In my opinion, major disadvantage of high-level languages (HLL) is obscure code generation.
Since HLL are not targeted for (not constrained with) any particular platform, code generation is left up to compiler vendor (developer). It is OK in case when hardware constraints on the target platform are pretty much loose and system (product) built with it does not violate the requirements. However, when tough hardware constraints come across tight system requirements, engineers need more control on the produced code. Usually such challenges are solved with assemblers, either inline or interfaced via object files. Some of HLLs (such as C) provide good facilities for interfacing with assembler code, some others not and this should be considered when choosing a language for an embedded project.
Besides obscure code generation, HLL and their compilers also contribute some constraints and limitations which may narrow down the space of design decisions.

Major advantages of HLL are better capabilities for code structuring and inter-module interfacing, stronger syntax constraints and, generally speaking, portability. Once you l have learned C, you can use your knowledge on x86, PIC, ARM, and so on.

Strengths of HLL are the weaknesses of assemblers. Their poor syntax control may turn a simple typo into a hard to find problem, poor capabilities inter-module interfacing creates difficulties for developing large projects, reusing the code and creating libraries.

Another crucial disadvantage of assemblers ??“ instruction syntax. The way it is done now has not been changed for sixty years. At that time there were good excuses for this kind of syntax, nowadays it looks like a religious dogma.