FreeCalypso > hg > freecalypso-docs

comparison FC-handset-spec @ 41:7d77aa76bcaa

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
FC-handset-spec: beginning of massive document
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 10 Jun 2021 07:16:17 +0000
parents
children 6b61d77f7700
comparison
equal deleted inserted replaced
40:1cdd0f0a6e70 41:7d77aa76bcaa
1 FreeCalypso Handset Specification
2 =================================
3
4 The purpose of this document is two-fold:
5
6 1) This document serves as the principal design specification for the
7 FreeCalypso Libre Dumbphone handset hardware which I, Mother Mychaela,
8 seek to build.
9
10 2) This document also defines the scope of functionality to be supported in
11 FreeCalypso handset firmware, including support for additional hardware
12 targets beyond the primary FC handset hw target.
13
14 1. FC handset hardware specification
15
16 1.1. Basic features
17
18 The Mother's goal is to produce a replacement for the proprietary Pirelli DP-L10
19 phone, or more specifically, for the GSM-only subset of this Pirelli phone which
20 the Mother actually uses, *without* Pirelli's key differentiating feature of
21 non-GSM WiFi operation, and without Pirelli's camera. The following hardware
22 features are to be included:
23
24 * 176x220 pixel color display (no touch)
25 * 21-button main keypad
26 * 3 side buttons for volume control and an auxiliary function
27 * USB port that combines charging and computer interface
28 * wired headset jack
29 * single SIM slot
30
31 The following features which are commonly found in mainstream proprietary
32 phones, particularly more recent ones, will NOT be included:
33
34 * camera
35 * Bluetooth
36 * FM radio
37 * TV receiver
38 * GPS receiver
39 * dual SIM slot
40 * torch light beyond LCD and keypad backlights
41
42 1.2. RF band capability
43
44 Our FC handset needs to be quadband GSM; this quadband capability will be
45 achieved by copying the RF section and the core PCB layout around it from the
46 reverse-engineered iWOW TR-800 modem module, which is itself a very direct
47 (almost verbatim) derivative of TI's Leonardo+ quadband reference design.
48
49 1.3. RAM and flash
50
51 The Mother's intent is to use Spansion S71PL064JA0 flash+RAM MCP on the final
52 handset motherboard, providing 8 MiB of flash and 2 MiB of XRAM in a 7x9 mm
53 footprint. This flash and RAM capacity is already known to be fully sufficient
54 for our FreeCalypso handset firmware in maximal feature configuration, hence
55 any larger capacity would be excessive. However, on our FC Venus development
56 board we may use the larger S71PL129NC0 MCP, same as used on FCDEV3B V2.
57
58 1.4. Liquid crystal display
59
60 1.4.1. Display size
61
62 The size of the display for our FC Libre Dumbphone handset design is fixed at
63 176x220 pixels, 16-bit color, following TI's D-Sample platform and the starting
64 point UI code that was developed for it. Thoughts of changing to a different
65 display size have been considered and rejected:
66
67 * If we were to change to a smaller display size, we would have to do extra work
68 on the firmware to shrink the UI to the smaller size, and we would reduce the
69 amount of information that can be displayed at once. We would incur extra
70 work and a functional loss, but gain absolutely nothing in return.
71
72 * If we were to change to a larger display size (240x320 pixels seems to be the
73 largest reasonable size for dumbphones, used in high-end Nokia models), we
74 would be venturing into uncertain territory - the greatest uncertainty would
75 be the extra CPU load on Calypso to draw the larger UI and to refresh the
76 larger framebuffer, which is done with PIO on Calypso, without any DMA
77 assistance. The D-Sample LCD size of 176x220 pixels already appears to be a
78 strain in some drawing code paths, hence the Mother's decision is to play it
79 safe and stick with the known working display size. Expanding the UI to make
80 sensible use of larger screen real estate would also entail additional work.
81
82 176x220 is the display size in pixels, and this resolution number by itself says
83 nothing about the physical display size in inches or mm. However, most readily
84 available LCDs that are made for this pixel resolution are made in 2.0" diagonal
85 physical size, with 31.68x39.60 mm active area and 0.180 mm dot pitch, hence
86 this physical size is the one we are going to use.
87
88 1.4.2. Specific LCD module selection
89
90 As of this writing, the specific LCD module to be used has not been firmly
91 selected yet. We are actively looking for an LCD module that fits all of the
92 following requirements:
93
94 * TFT color LCD, 2.0" diagonal, 176x220 pixel resolution;
95
96 * 16-bit microprocessor bus interface;
97
98 * 6:00 viewing direction as appropriate for cellular handsets;
99
100 * backlight consisting of 3 white LEDs in parallel, joined at the anode,
101 with separately brought-out cathodes;
102
103 * mechanical design that supports mounting with the FPC tail folded under the
104 module, either by way of direct solder termination (no connector) or by way
105 of raised sides that create sufficient vertical space to accommodate the FPC
106 connector.
107
108 The requirement of 16-bit microprocessor bus interface stems from the desire to
109 interface this LCD to the Calypso in exactly the same way how TI did it on the
110 D-Sample, the 6:00 viewing direction and mechanical mounting requirements stem
111 naturally from the target application (cellular phone handset), and the
112 backlight LED wiring requirement stems from the constraints of our chosen
113 MAX1916 backlight LED driver chip - see section 1.4.4.
114
115 1.4.3. Backlight and readability considerations
116
117 Out of the various pre-existing mobile phones which I (Mychaela) have
118 experienced, there have been 3 different kinds of LCDs in terms of how display
119 operation and readability interacts with the backlight:
120
121 1) older phones with black&white LCDs: on all phones of this type which I've
122 ever used, the display is perfectly readable without the backlight given
123 ordinary ambient lighting, be it natural daylight or room lighting. Such
124 LCDs are called reflective. With these B&W displays, you only need to turn
125 on the backlight if you need to operate the phone in darkness, such as
126 outdoors at night or inside with all lights off. The firmware in such phones
127 is typically designed to leave the actual display functional and updated at
128 all times, with only the backlight subject to on/off control.
129
130 2) most newer phones with color displays, of which Pirelli DP-L10 is a
131 representative case, have transmissive LCDs that are not designed to be
132 readable without the backlight at all - backlight required for readability
133 (BLRR) is another way to describe such LCDs. Because the display is not
134 readable at all without the backlight, phone firmware is typically designed
135 to turn off the entire display (not just the backlight) when the screen goes
136 dark, and operation visible to the user is display on/off, rather than
137 backlight on/off. It is a good firmware design practice to "swallow" the
138 initial keypress that turns on the display from dark state, i.e., to block
139 the regular action of whatever button was pressed to "wake up" the display.
140
141 3) The color display on Motorola C139 phones is an odd intermediate case: this
142 display is NOT practically readable with the backlight off, yet the firmware
143 is designed as if the display were readable in this condition: the actual
144 display (unsure if it is CSTN or TFT) remains on and updated, and when you
145 press some button to "wake up" the display, that button still takes its
146 regular action, which is really bad for usability. How do we know that the
147 actual CSTN or TFT display remains on and actively updated when it is not
148 readable with the backlight off? Answer: the non-backlit display can be made
149 readable by shining a flashlight directly at it - but this trick requires a
150 directly pointed flashlight; no amount of ordinary ambient light is enough
151 to make the display readable.
152
153 Because our FC Libre Dumbphone handset will have a color display (contemporary
154 TFT) and because we are sane, not copying the monumental design mistake of Mot
155 C139, our display will fall into class 2 by the above classification: backlight
156 required for readability, full display on/off rather than just backlight on/off,
157 firmware operating like Pirelli's in terms of wake-up keypress swallowing.
158
159 1.4.3.1. Backlight dimming mode
160
161 Because our LCD is of BLRR type and because we seek to fully replicate Pirelli's
162 logic in terms of when keypresses are swallowed and when they are not, we need
163 to implement a dimming mode for our LCD backlight. In Pirelli's design which we
164 are copying, when you are playing with phone menus or composing SMS etc, but are
165 not in an active call, the display switches between full brightness and totally
166 off - it goes fully off on timeout, and when you press a button to wake it up,
167 it switches on at full brightness, together with the keypad backlight. But when
168 you are in a call, when the timer expires (and it's a shorter timer, 10 s
169 instead of 30 s), the display goes dim instead of fully off, and in this dimmed
170 (but still readable) state keypresses are NOT swallowed.
171
172 We only need to implement two different intensity levels for the LCD backlight:
173 full brightness and in-call dimmed. The backlight intensity level in the dimmed
174 state will need to chosen on this principle: use the lowest backlight LED
175 current (to conserve battery power and allow longest talk time on one charge) at
176 which the display is still readable, similarly to Pirelli's in-call dimmed
177 state.
178
179 In the user-actively-poking state, as opposed to the long-call dimmed state,
180 there is no need to provide different configurable backlight levels - see
181 section 1.4.5.
182
183 1.4.4. Backlight circuit implementation
184
185 In all candidate TFT LCD modules that are being considered (see section 1.4.2),
186 the backlight consists of 3 white LEDs wired in parallel, joined either at the
187 anode or at the cathode - although as we shall see momentarily, we require an
188 LCD module where the 3 LEDs are joined at the anode, with the 3 cathodes brought
189 out separately. LCD module datasheets call for 15 mA current through each LED
190 at maximum intensity, for 45 mA total, and the LED forward drop voltage (Vf) at
191 this rated current seems to range between 2.9 V (what I actually measured on one
192 candidate LCD module) to 3.2 V (what the datasheets list as typical) to perhaps
193 as high as 3.4 V (what one datasheet lists as the maximum).
194
195 Given the parallel (as opposed to series) wiring of the 3 LEDs and the
196 relatively low Vf, there is no need to use any kind of boost converter as part
197 of the LED driver circuit for this backlight - any boost converter will only add
198 inefficiency (more current will be drawn from the battery for the same LED
199 current), hence we need to avoid using such.
200
201 Regardless of whether a given phone design uses a boost converter or not (it
202 seems that older designs do use boost converters, either because older white
203 LEDs have higher Vf or because 2 or 3 LEDs are wired in series), all traditional
204 phone designs seem to share the quality where the display backlight brightness
205 remains the same as the battery discharges and as Vbat goes down - this quality
206 was directly observed on the Pirelli DP-L10 (unknown circuit design) and
207 inferred from the available schematics for Mot C139 and C155, with both of the
208 latter boost-converting to fixed 5.0 V. In our case, even though we choose to
209 not use a boost converter for efficiency reasons, we still need to achieve the
210 quality of the display brightness remaining the same through the discharge range
211 of our Li-ion battery - having the display dim in half as the battery discharges
212 from 4.2 V peak to 3.6-3.7 V plateau is simply not acceptable.
213
214 The simplest possible LED driving circuit would be one where a current limiting
215 resistor is inserted in series with each LED, and then the 3 parallel
216 LED+resistor sets are connected across battery terminals, with a transistor
217 inserted somewhere to act as the on/off switch. However, this trivial circuit
218 is not suitable in our application because it would produce unacceptably large
219 variation in display brightness as the battery discharges - hence we need a more
220 intelligent LED driving circuit. Our Luna LCD carrier board from the spring of
221 2020 features an LDO bringing Vbat down to fixed 3.5 V, followed by very low-
222 value resistors in series with each LED - but this approach is not good for
223 production either, as it makes the LED current extremely sensitive to any slight
224 variations in Vf.
225
226 Fortunately, I was able to find a specialized white LED driver chip that is just
227 perfect for our application, or more precisely, a specialized chip that acts as
228 a constant current sink for such LEDs - Maxim MAX1916, design from 2001, just
229 the right time frame for the kind of phone we are seeking to build. This
230 special chip takes the place of "dumb" ballast resistors: connect Vbat (battery
231 positive terminal) directly to the common anode of the 3 LEDs, but instead of
232 series resistors, connect each cathode to the corresponding LEDn pin of MAX1916
233 - *without* any resistors or transistors! FETs inside the MAX1916 take the
234 place of resistors as current-limiting elements, and the chip's global on/off
235 control takes the place of a separate switching transistor.
236
237 The special quality of MAX1916 is that it produces constant current through each
238 LED (based on a set reference current and 230x current multiplication circuit
239 inside the chip) regardless of variations in both Vbat and Vf! Of course the
240 requested current can only be sustained as long as Vbat >= Vf + Vds, where Vds
241 is the lowest drop voltage of the FETs inside MAX1916, and once Vbat falls below
242 this point, the LED current will begin to decline. However, the beauty of this
243 design is that no arbitrary artificial turnover points (like the 3.5 V point in
244 our hacky design from the spring of 2020) need to be set: the battery discharge
245 point at which the LED current begins to decline will be whatever it comes to be
246 naturally, based on Vf (perhaps depending on temperature) and MAX1916 Vds, and
247 the decline is expected to be gradual.
248
249 1.4.4.1. Backlight current selection and dimming
250
251 In the simplest MAX1916-based design, a fixed LED current is set by connecting
252 a resistor of appropriately computed value between MAX1916 SET pin and whatever
253 regulated fixed voltage rail happens to be available in the system. However,
254 in our application (see section 1.4.3.1) we need at least two different display
255 brightness levels, and thus at least two switchable LED currents. At first the
256 problem seems difficult, but an elegant solution has been found.
257
258 LCD backlight LED current will be selected by way of two Calypso GPIO pins
259 configured as outputs, and a 74LVC2G125 dual tristate buffer. Each tristate
260 buffer's A input will be tied high, and the two Calypso GPIO outputs will be
261 connected to buffer output enable inputs. There will be two resistors with
262 different carefully computed values, each connected between one of the two
263 tristate buffer outputs and MAX1916 SET pin. One resistor will provide a small
264 current, the other will provide a large current, and each of these two currents
265 will be switchable on/off by Calypso GPIO signals switching the buffer outputs
266 between driving high (2.7-2.8 V) and Hi-Z. Resistor values will be chosen such
267 that the sum of both currents will be the 15 mA limit (the current is reckoned
268 per LED), whereas the small current alone will be whatever we need for the
269 battery-saving long-call dimmed mode.
270
271 1.4.5. Slight regression relative to Pirelli DP-L10
272
273 The actual LCD backlight LED driving circuit inside the Pirelli phone is not
274 known, but reverse engineering of Pirelli's firmware followed by experimentation
275 reveals that backlight intensity variation is achieved via a form of PWM, using
276 Calypso PWL output - although PWL is used in an inverted sense, such that the
277 backlight intensity increases with more 0s being put out on PWL, as opposed to
278 more 1s. Thus regardless of the unknown actual circuit implementation, the
279 backlight intensity appears to be continuously variable from 1/255 to 255/255,
280 which is certainly a much richer control than our crude selection of just 3
281 possible LED currents.
282
283 In terms of what Pirelli's fw offers to end users, the backlight intensity in
284 the dimmed in-call state is always set to 1/255, without any way to change it,
285 whereas the backlight intensity in the active interaction state is selectable
286 via a menu among 5 levels; the 5 offered levels turn into 1/255, 64/255,
287 128/255, 192/255 and 255/255 in the resulting PWL programming.
288
289 So in terms of both hardware capabilities and end user offering via the
290 firmware, Pirelli's LCD backlight level control is richer than what we are
291 proposing for our FC Libre Dumbphone. However, engineering is all about
292 trade-offs and compromises, and in the Mother's opinion, this slight reduction
293 in the richness of functionality is sufficiently offset by the efficiency of
294 our MAX1916-based approach: aside from the theoretical possibility of a
295 switching buck converter, which I've never seen used for LED driving
296 applications, our choice of MAX1916 is the most battery-efficient way to drive
297 our backlight LEDs. Furthermore, when dimming is effected by switching the
298 actual regulated LED current, as in our case, as opposed to applying PWM, our
299 backlight becomes more resilient to even lower battery voltages.
300
301 Consider what happens when Vbat falls below the point at which the design-
302 intended LED current can be maintained - what happens then? If no PWM is
303 applied, or if PWM is set to maximum, then display brightness will be whatever
304 maximum is possible at this low battery voltage. But if PWM is applied,
305 especially very low duty cycles as in the case of Pirelli's dimmed state, then
306 the display that has already been dimmed by low Vbat will be *further* dimmed
307 by this aggressive PWM, likely producing an unreadable display at this point.
308 It may be possible to compensate via extra complexity in the firmware, by
309 turning PWM up when Vbat (as measured via Iota MADC) falls too low - but then
310 we would be getting really messy, whereas switching the regulated current is so
311 much more elegant. With our approach, low-battery-induced dimming in the "full
312 brightness" mode will happen at the same discharge point as it would if we had
313 used PWM (and set PWM to maximum in this "full brightness" mode), but in the
314 in-call dimmed state, further dimming due to low Vbat will probably happen at a
315 lower discharge point (if Vf decreases with decreasing current), and when it
316 does happen, there won't be a combination of both natural and artificially-
317 induced reductions, just the natural one.
318
319 Thus based on all of the above considerations, I feel justified in my design
320 choice of foregoing PWM control of backlight intensity in favor of fixed current
321 switching with much more limited selection.