--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/LCD-backlight-driver	Sun May 10 22:48:39 2020 +0000
@@ -0,0 +1,216 @@
+I, Mother Mychaela, have a deep desire to build my own GSM cellphone handset
+that would serve as a published-source replacement for my current Pirelli
+DP-L10, which is laden with unwanted and undocumented extra non-GSM components
+and for which there are no schematics.  I already know what kind of display I
+wish to use in my dream FreeCalypso Libre Dumbphone: a 2.0" 176x220 pixel TFT
+color LCD, strictly transmissive, requiring a backlight - same principal class
+of LCD as in the Pirelli DP-L10, but stepping up in size from Pirelli's 128x128
+to 176x220 pixels.  There are many vendors who make suitable LCD modules, and
+there are two specific candidate modules already in use at FreeCalypso HQ as
+part of various prototype rigs.
+
+The backlight is implemented in exactly the same way on all candidate 2.0"
+176x220 pixel TFT LCD modules I have looked at: it consists of 3 white LEDs,
+joined together either at the anode or at the cathode, with the opposite
+terminal brought out separately for each of the 3 LEDs, supporting an
+arrangement where the 3 LEDs are driven in parallel rather than in series.
+Each of the 3 LEDs needs to have about 15 mA flowing through it for maximum
+display brightness; lower LED currents will produce lower display brightness,
+but going significantly above 15 mA would be bad - too much current would burn
+out the LEDs.
+
+Exactly how should this backlight be driven in our FreeCalypso Libre Dumbphone
+design?  In this article I am going to look at some obvious and less obvious
+ways to drive backlight LEDs, and then present my own novel way (novel in that
+I haven't seen it used in any existing design or seen it recommended anywhere)
+which has already been implemented on our current Luna development platform.
+
+The trivial way: VBAT and series resistors
+==========================================
+
+The most trivial way to drive a backlight LED or a parallel group of such LEDs
+in a mobile phone whose ultimate power source is a single-cell Li-ion battery
+would be to put a current limiting resistor in series with each LED, and then
+connect each LED+resistor set between VBAT and GND, i.e., across battery
+terminals.  (Of course a transistor would also need to be inserted somewhere to
+act as on/off switch, turning the backlight on only when it is needed.)
+
+With this trivial arrangement the value of the series resistors (one in series
+with each LED) would need to be calculated as follows:
+
+R = (VBAT_max - Vled) / Iled_max
+
+where VBAT_max is the maximum allowed battery voltage (4.2 V for typical Li-ion
+batteries), Vled is the voltage drop across a backlight LED, and Iled_max is the
+maximum current that should ever flow through each individual LED.
+
+The big problem with this trivial LED driver approach is that the display
+backlight will glow at its maximum brightness only when the battery is at its
+peak charge, and will dim as the battery discharges.  Why so?  The series
+resistor value would need to be set per the equation above in order to avoid
+damage to the backlight LEDs (the current through each LED must not exceed
+Iled_max at the highest battery voltage), but then as the battery discharges,
+the voltage across each LED series resistor will decline (VBAT - Vled, with
+Vled assumed to be constant), and the current through the resistor (and thus
+through the LED as well) will decline proportionally.
+
+How do LCD backlights in mainstream commercial phones behave in this regard?
+I have a disassembled Pirelli DP-L10 phone (bare motherboard with the LCD and
+the keypad still attached) which I have hacked up to be powered by a lab bench
+power supply instead of the usual battery, and I did an experiment with it: I
+powered up this Pirelli motherboard with my bench supply, running Pirelli's
+original firmware, I got it into a state where both LCD and keypad backlights
+are on (press any keypad button to turn them back on when the fw turns them off
+by timeout), I turned the voltage knob on the power supply up and down, and I
+observed the brightness of both LCD and keypad backlights.
+
+Observation: Pirelli's keypad backlight does get noticeably brighter or dimmer
+as VBAT goes up and down, indicating that they do use the trivial driver circuit
+for this one (from fw perspective, Pirelli's keypad backlight is driven or at
+least controlled with Iota LED-B), but the LCD brightness stays exactly the same
+as VBAT ranges from the 4.2 V Li-ion maximum to the low-battery emergency
+shut-off voltage (about 2.8 V) at which the Iota VRPC block involuntarily shuts
+down the entire Calypso subsystem.
+
+It is not clear exactly how Pirelli's LCD backlight driver circuit is
+implemented.  There is a component on their motherboard near the LCD connector
+marked as A3-90E - it might be the LED driver - and there is another little
+component next to it that looks like an inductor, suggesting some kind of boost
+converter.  There is no documentation for Pirelli's Giantplus GPM526A0 LCD
+module, but it seems to have just two wires for the backlight, suggesting that
+the two backlight LEDs (this LCD module has 2 backlight LEDs rather than 3) may
+be wired in series (not parallel), in which case a boost converter would be
+absolutely required.
+
+Boost to 5V, then fixed series resistors
+========================================
+
+The available schematics for Motorola C139 and C155 phones depict an LCD
+backlight driver circuit that seemed bizarre to me at first: they take VBAT,
+boost it up to constant 5V with a step-up charge pump (RT9361A on C139
+schematics, REG710NA-5 on C155 schematics), and feed that 5V to their LCD
+module, which presumably expects fixed 5V backlight power and internally
+contains a fixed resistor in series with each LED.
+
+This approach certainly accomplishes the goal of constant LCD backlight
+brightness irrespective of battery state of charge, but it does so at a huge
+cost in terms of efficiency.  Both RT9361A and REG710NA-5 are step-up charge
+pumps, and they work by doubling the current draw.  If we were to use the same
+arrangement for our LCD backlight (3 LEDs, each needing 15 mA), then for 45 mA
+of current flowing through the LEDs, 90 mA will be drawn from the battery.
+These are not "smart" boost converters that draw less input current as their
+input voltage goes up (for same I*V power), instead the input current is an
+almost constant 2x the output current, thus the overall efficiency gets very
+poor at higher battery voltages.
+
+I strongly dislike this approach for its wastefulness, hence I sought another
+way.
+
+My novel 3.5V LDO approach
+==========================
+
+Datasheets for the LCD modules I am working with specify the drop voltage across
+each of the 3 backlight LEDs as 3.2V.  The table of battery voltage thresholds
+(mapping VBAT to battery state of charge percentages) inside Pirelli's firmware
+(located and extracted via thorough reverse eng) has these mappings at the lower
+end:
+
+3719	20
+3688	15
+3663	10
+3539	5
+3370	0
+
+These numbers make it clear that a battery voltage around 3.5 to 3.6 V means
+that the battery is near empty; combining this "low battery" number with the
+datsheet-stated LED drop voltage of 3.2 V gave me this idea: what if we feed
+VBAT to a 3.5V LDO regulator and use this LDO output as the backlight power
+source, with the LED series resistor values computed for 3.5 V supply?  This
+approach would produce constant LCD brightness for the wide VBAT range from
+just above 3.5 V (the LDO regulator's dropout is very low) to 4.2 V or above,
+without doubling the current draw (for 45 mA flowing through the LEDs,
+approximately the same 45 mA will be drawn from the battery), with the only
+anticipated penalty being a possible sharp drop-off in LCD brightness when the
+battery gets critically low.
+
+When I was designing my FC Luna UI development platform (an LCD add-on to the
+existing historical third-party Caramel board), I sought to test this idea
+empirically.  But before actually building this Luna LCD board, I fortunately
+had the foresight to measure the actual voltage drop across the backlight LEDs,
+rather than blindly rely on the datasheet spec of 3.2 V.  Back in 2018 I had
+tested my chosen LCD modules in a standalone environment without Calypso: I had
+them switched into 8-bit microprocessor bus interface mode (IM0 pin strapping)
+and I drove them with an FT2232D adapter using FTDI's MCU host bus emulation
+mode.  I still have the two hardware setups (LCD modules from two different
+vendors) I had put together back then; the backlight power source in these
+setups is USB 5V, with 110 or 120 ohm LED series resistors.  I took the one
+setup on which the point between each LED cathode and the connected series
+resistor is easily accessible for probing, and I measured the voltage at that
+point, to see how the overall 5V gets split between the drop across the LED and
+the drop across the resistor.
+
+The answer was somewhat unexpected: the voltage drop across each LED turned out
+to be somewhere around 2.9 V, as opposed to the 3.2 V datasheet number.  This
+difference in the LED forward drop voltage does highlight one major weakness of
+my close-to-Vled LDO approach: by setting the backlight fixed voltage so close
+to the expected forward drop voltage of the actual LEDs, I am making my circuit
+extremely sensitive to slight variations in that forward drop voltage.  If I
+had populated LED series resistors on my Luna LCD board based on the 3.2 V
+assumption (assuming 300 mV drop across each resistor), then the current flowing
+through the LEDs would be double of my design intent (with Vled = 2.9 V, the
+voltage drop across each resistor becomes 600 mV), possibly burning out the
+LEDs!  In contrast, a circuit in which each LED+resistor set is driven with a
+much higher voltage (meaning a larger voltage drop across the resistor and a
+larger resistor value) is much less sensitive to variations in Vled, producing
+much less resulting variation in Iled.
+
+I ended up building my Luna LCD board with my 3.5V LDO backlight LED driver
+circuit intact, but I populated 38.3 ohm series resistors instead of my
+originally intended 20 ohm value.  The resulting circuit works well in practice:
+the LDO puts out a very precise 3.5 V for any higher VBAT input, the LCD
+backlight is bright and visually pleasing, the measured voltage drop across the
+resistors with the backlight on is right about 600 mV, meaning that the 2.9 V
+LED forward drop voltage hasn't changed, and the current flowing through each
+LED is in the desired 15-16 mA target range.  The LDO regulator's enable input
+also conveniently serves as the backlight on/off control, driven by Calypso
+GPIO 9 in the complete Luna setup.  (Calypso MCSI is used only in modem configs,
+not in handset configs, thus MCSI pins become GPIOs in the latter, available for
+functions like LCD backlight control.)
+
+I then set out to test what happens when the VBAT input to my Luna LCD backlight
+driver falls below 3.5 V.  At lower voltages the LDO regulator becomes
+essentially a pass-through, with the low battery voltage applied almost directly
+to each LED+resistor set.  The current flowing through the LEDs falls
+accordingly, but the question to be answered was what happens to the visual
+readability of the LCD.  The answer turned out to be very positive: I set my
+VBAT-generating lab bench power supply as low as 2.8 V (the emergency shut-off
+voltage for Iota VRPC), and while the display naturally gets very dimmed, it is
+still readable!  This finding tells us that my 3.5V LDO approach does not
+present the problem I was afraid of (the display going totally dark in
+critically low battery scenarios when the rest of the phone still has some life
+left), and the only remaining concern with this approach is the extremely high
+sensitivity to variations in LED forward drop voltage.
+
+Where to go from here
+=====================
+
+If I ever get as far as actually building my desired FreeCalypso dream phone,
+what LCD backlight driver circuit should I use?  Should I keep the 3.5V LDO
+circuit that appears to work OK in our current Luna setup, or would I be heading
+into trouble with LED forward drop voltage variations?  I *really* dislike the
+wastefulness of the seemingly-mainstream approach (boost converter to a higher
+voltage, then series resistors based on that higher voltage), but I don't know
+of any better alternative.  If someone with better EE knowledge can suggest a
+non-wasteful approach that would eliminate or at least reduce Vled sensitivity,
+it would be great, otherwise I will have to stick with my current approach and
+hope for the best.
+
+I also desire to add PWM control to this LCD backlight, so that the 45 mA
+brightness will be the available maximum, rather than required at all times.
+The plan I have in mind is to insert a transistor between the cathode joining
+point (where either the 3 LED cathodes or the 3 resistors connected to these
+cathodes join) and GND, controlled by Calypso PWL output.  Unfortunately this
+approach would be difficult to prototype in our current Luna environment
+because Calypso LT/PWL output is not easily accessible on the Caramel board: it
+does come out of the core module, but it goes to an on-board transistor for an
+on-board indicator LED, and does not go to any header pins or test points.