FreeCalypso > hg > freecalypso-hwlab

comparison doc/LCD-backlight-driver @ 70:b1b027efce8e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/LCD-backlight-driver article written
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 10 May 2020 22:48:39 +0000
parents
children
comparison
equal deleted inserted replaced
69:1e6f05ede5ca 70:b1b027efce8e
1 I, Mother Mychaela, have a deep desire to build my own GSM cellphone handset
2 that would serve as a published-source replacement for my current Pirelli
3 DP-L10, which is laden with unwanted and undocumented extra non-GSM components
4 and for which there are no schematics. I already know what kind of display I
5 wish to use in my dream FreeCalypso Libre Dumbphone: a 2.0" 176x220 pixel TFT
6 color LCD, strictly transmissive, requiring a backlight - same principal class
7 of LCD as in the Pirelli DP-L10, but stepping up in size from Pirelli's 128x128
8 to 176x220 pixels. There are many vendors who make suitable LCD modules, and
9 there are two specific candidate modules already in use at FreeCalypso HQ as
10 part of various prototype rigs.
11
12 The backlight is implemented in exactly the same way on all candidate 2.0"
13 176x220 pixel TFT LCD modules I have looked at: it consists of 3 white LEDs,
14 joined together either at the anode or at the cathode, with the opposite
15 terminal brought out separately for each of the 3 LEDs, supporting an
16 arrangement where the 3 LEDs are driven in parallel rather than in series.
17 Each of the 3 LEDs needs to have about 15 mA flowing through it for maximum
18 display brightness; lower LED currents will produce lower display brightness,
19 but going significantly above 15 mA would be bad - too much current would burn
20 out the LEDs.
21
22 Exactly how should this backlight be driven in our FreeCalypso Libre Dumbphone
23 design? In this article I am going to look at some obvious and less obvious
24 ways to drive backlight LEDs, and then present my own novel way (novel in that
25 I haven't seen it used in any existing design or seen it recommended anywhere)
26 which has already been implemented on our current Luna development platform.
27
28 The trivial way: VBAT and series resistors
29 ==========================================
30
31 The most trivial way to drive a backlight LED or a parallel group of such LEDs
32 in a mobile phone whose ultimate power source is a single-cell Li-ion battery
33 would be to put a current limiting resistor in series with each LED, and then
34 connect each LED+resistor set between VBAT and GND, i.e., across battery
35 terminals. (Of course a transistor would also need to be inserted somewhere to
36 act as on/off switch, turning the backlight on only when it is needed.)
37
38 With this trivial arrangement the value of the series resistors (one in series
39 with each LED) would need to be calculated as follows:
40
41 R = (VBAT_max - Vled) / Iled_max
42
43 where VBAT_max is the maximum allowed battery voltage (4.2 V for typical Li-ion
44 batteries), Vled is the voltage drop across a backlight LED, and Iled_max is the
45 maximum current that should ever flow through each individual LED.
46
47 The big problem with this trivial LED driver approach is that the display
48 backlight will glow at its maximum brightness only when the battery is at its
49 peak charge, and will dim as the battery discharges. Why so? The series
50 resistor value would need to be set per the equation above in order to avoid
51 damage to the backlight LEDs (the current through each LED must not exceed
52 Iled_max at the highest battery voltage), but then as the battery discharges,
53 the voltage across each LED series resistor will decline (VBAT - Vled, with
54 Vled assumed to be constant), and the current through the resistor (and thus
55 through the LED as well) will decline proportionally.
56
57 How do LCD backlights in mainstream commercial phones behave in this regard?
58 I have a disassembled Pirelli DP-L10 phone (bare motherboard with the LCD and
59 the keypad still attached) which I have hacked up to be powered by a lab bench
60 power supply instead of the usual battery, and I did an experiment with it: I
61 powered up this Pirelli motherboard with my bench supply, running Pirelli's
62 original firmware, I got it into a state where both LCD and keypad backlights
63 are on (press any keypad button to turn them back on when the fw turns them off
64 by timeout), I turned the voltage knob on the power supply up and down, and I
65 observed the brightness of both LCD and keypad backlights.
66
67 Observation: Pirelli's keypad backlight does get noticeably brighter or dimmer
68 as VBAT goes up and down, indicating that they do use the trivial driver circuit
69 for this one (from fw perspective, Pirelli's keypad backlight is driven or at
70 least controlled with Iota LED-B), but the LCD brightness stays exactly the same
71 as VBAT ranges from the 4.2 V Li-ion maximum to the low-battery emergency
72 shut-off voltage (about 2.8 V) at which the Iota VRPC block involuntarily shuts
73 down the entire Calypso subsystem.
74
75 It is not clear exactly how Pirelli's LCD backlight driver circuit is
76 implemented. There is a component on their motherboard near the LCD connector
77 marked as A3-90E - it might be the LED driver - and there is another little
78 component next to it that looks like an inductor, suggesting some kind of boost
79 converter. There is no documentation for Pirelli's Giantplus GPM526A0 LCD
80 module, but it seems to have just two wires for the backlight, suggesting that
81 the two backlight LEDs (this LCD module has 2 backlight LEDs rather than 3) may
82 be wired in series (not parallel), in which case a boost converter would be
83 absolutely required.
84
85 Boost to 5V, then fixed series resistors
86 ========================================
87
88 The available schematics for Motorola C139 and C155 phones depict an LCD
89 backlight driver circuit that seemed bizarre to me at first: they take VBAT,
90 boost it up to constant 5V with a step-up charge pump (RT9361A on C139
91 schematics, REG710NA-5 on C155 schematics), and feed that 5V to their LCD
92 module, which presumably expects fixed 5V backlight power and internally
93 contains a fixed resistor in series with each LED.
94
95 This approach certainly accomplishes the goal of constant LCD backlight
96 brightness irrespective of battery state of charge, but it does so at a huge
97 cost in terms of efficiency. Both RT9361A and REG710NA-5 are step-up charge
98 pumps, and they work by doubling the current draw. If we were to use the same
99 arrangement for our LCD backlight (3 LEDs, each needing 15 mA), then for 45 mA
100 of current flowing through the LEDs, 90 mA will be drawn from the battery.
101 These are not "smart" boost converters that draw less input current as their
102 input voltage goes up (for same I*V power), instead the input current is an
103 almost constant 2x the output current, thus the overall efficiency gets very
104 poor at higher battery voltages.
105
106 I strongly dislike this approach for its wastefulness, hence I sought another
107 way.
108
109 My novel 3.5V LDO approach
110 ==========================
111
112 Datasheets for the LCD modules I am working with specify the drop voltage across
113 each of the 3 backlight LEDs as 3.2V. The table of battery voltage thresholds
114 (mapping VBAT to battery state of charge percentages) inside Pirelli's firmware
115 (located and extracted via thorough reverse eng) has these mappings at the lower
116 end:
117
118 3719 20
119 3688 15
120 3663 10
121 3539 5
122 3370 0
123
124 These numbers make it clear that a battery voltage around 3.5 to 3.6 V means
125 that the battery is near empty; combining this "low battery" number with the
126 datsheet-stated LED drop voltage of 3.2 V gave me this idea: what if we feed
127 VBAT to a 3.5V LDO regulator and use this LDO output as the backlight power
128 source, with the LED series resistor values computed for 3.5 V supply? This
129 approach would produce constant LCD brightness for the wide VBAT range from
130 just above 3.5 V (the LDO regulator's dropout is very low) to 4.2 V or above,
131 without doubling the current draw (for 45 mA flowing through the LEDs,
132 approximately the same 45 mA will be drawn from the battery), with the only
133 anticipated penalty being a possible sharp drop-off in LCD brightness when the
134 battery gets critically low.
135
136 When I was designing my FC Luna UI development platform (an LCD add-on to the
137 existing historical third-party Caramel board), I sought to test this idea
138 empirically. But before actually building this Luna LCD board, I fortunately
139 had the foresight to measure the actual voltage drop across the backlight LEDs,
140 rather than blindly rely on the datasheet spec of 3.2 V. Back in 2018 I had
141 tested my chosen LCD modules in a standalone environment without Calypso: I had
142 them switched into 8-bit microprocessor bus interface mode (IM0 pin strapping)
143 and I drove them with an FT2232D adapter using FTDI's MCU host bus emulation
144 mode. I still have the two hardware setups (LCD modules from two different
145 vendors) I had put together back then; the backlight power source in these
146 setups is USB 5V, with 110 or 120 ohm LED series resistors. I took the one
147 setup on which the point between each LED cathode and the connected series
148 resistor is easily accessible for probing, and I measured the voltage at that
149 point, to see how the overall 5V gets split between the drop across the LED and
150 the drop across the resistor.
151
152 The answer was somewhat unexpected: the voltage drop across each LED turned out
153 to be somewhere around 2.9 V, as opposed to the 3.2 V datasheet number. This
154 difference in the LED forward drop voltage does highlight one major weakness of
155 my close-to-Vled LDO approach: by setting the backlight fixed voltage so close
156 to the expected forward drop voltage of the actual LEDs, I am making my circuit
157 extremely sensitive to slight variations in that forward drop voltage. If I
158 had populated LED series resistors on my Luna LCD board based on the 3.2 V
159 assumption (assuming 300 mV drop across each resistor), then the current flowing
160 through the LEDs would be double of my design intent (with Vled = 2.9 V, the
161 voltage drop across each resistor becomes 600 mV), possibly burning out the
162 LEDs! In contrast, a circuit in which each LED+resistor set is driven with a
163 much higher voltage (meaning a larger voltage drop across the resistor and a
164 larger resistor value) is much less sensitive to variations in Vled, producing
165 much less resulting variation in Iled.
166
167 I ended up building my Luna LCD board with my 3.5V LDO backlight LED driver
168 circuit intact, but I populated 38.3 ohm series resistors instead of my
169 originally intended 20 ohm value. The resulting circuit works well in practice:
170 the LDO puts out a very precise 3.5 V for any higher VBAT input, the LCD
171 backlight is bright and visually pleasing, the measured voltage drop across the
172 resistors with the backlight on is right about 600 mV, meaning that the 2.9 V
173 LED forward drop voltage hasn't changed, and the current flowing through each
174 LED is in the desired 15-16 mA target range. The LDO regulator's enable input
175 also conveniently serves as the backlight on/off control, driven by Calypso
176 GPIO 9 in the complete Luna setup. (Calypso MCSI is used only in modem configs,
177 not in handset configs, thus MCSI pins become GPIOs in the latter, available for
178 functions like LCD backlight control.)
179
180 I then set out to test what happens when the VBAT input to my Luna LCD backlight
181 driver falls below 3.5 V. At lower voltages the LDO regulator becomes
182 essentially a pass-through, with the low battery voltage applied almost directly
183 to each LED+resistor set. The current flowing through the LEDs falls
184 accordingly, but the question to be answered was what happens to the visual
185 readability of the LCD. The answer turned out to be very positive: I set my
186 VBAT-generating lab bench power supply as low as 2.8 V (the emergency shut-off
187 voltage for Iota VRPC), and while the display naturally gets very dimmed, it is
188 still readable! This finding tells us that my 3.5V LDO approach does not
189 present the problem I was afraid of (the display going totally dark in
190 critically low battery scenarios when the rest of the phone still has some life
191 left), and the only remaining concern with this approach is the extremely high
192 sensitivity to variations in LED forward drop voltage.
193
194 Where to go from here
195 =====================
196
197 If I ever get as far as actually building my desired FreeCalypso dream phone,
198 what LCD backlight driver circuit should I use? Should I keep the 3.5V LDO
199 circuit that appears to work OK in our current Luna setup, or would I be heading
200 into trouble with LED forward drop voltage variations? I *really* dislike the
201 wastefulness of the seemingly-mainstream approach (boost converter to a higher
202 voltage, then series resistors based on that higher voltage), but I don't know
203 of any better alternative. If someone with better EE knowledge can suggest a
204 non-wasteful approach that would eliminate or at least reduce Vled sensitivity,
205 it would be great, otherwise I will have to stick with my current approach and
206 hope for the best.
207
208 I also desire to add PWM control to this LCD backlight, so that the 45 mA
209 brightness will be the available maximum, rather than required at all times.
210 The plan I have in mind is to insert a transistor between the cathode joining
211 point (where either the 3 LED cathodes or the 3 resistors connected to these
212 cathodes join) and GND, controlled by Calypso PWL output. Unfortunately this
213 approach would be difficult to prototype in our current Luna environment
214 because Calypso LT/PWL output is not easily accessible on the Caramel board: it
215 does come out of the core module, but it goes to an on-board transistor for an
216 on-board indicator LED, and does not go to any header pins or test points.