• Intro
• Downloads
• Community
• Development
• News
• TALK

N900 Hardware Subsystems

There are many interacting hardware subsystems in the N900.

These can be split roughly into several areas.

Contents 1 Audio 1.1 Software 1.2 Main Speakers 1.3 Earpiece 1.4 Headphones 1.5 Composite out 1.6 FM radio transmitter 1.7 FM radio receiver 1.8 Bluetooth audio 2 Video 2.1 Display 2.1.1 Built in LCD 2.1.2 Composite out 2.2 Front camera (VGA) 2.3 Rear camera (5MP) 2.3.1 Rear camera autofocus 2.3.2 Rear camera LED flash 2.3.3 Rear camera warning light 2.3.4 Rear camera shutter 3 USB 3.1 USB socket 4 User interaction 4.1 Touchscreen 4.2 Accelerometer 4.3 Switches 4.3.1 Lock Switch 4.3.2 Headset Switch 4.3.3 Jack Switch 4.3.4 Camera Button 4.3.5 Power Button 4.3.6 Volume control 4.3.7 Rear cover presence switch 4.3.8 Camera cover 4.4 Keyboard 4.4.1 Keyboard Slide 4.5 Proximity sensor 4.6 Ambient Light Meter 5 Power management 5.1 Battery 5.1.1 Charge meter 5.2 Battery Charger 5.3 Gaia 5.4 CPU 6 Phone 6.1 GPS 6.2 2G/3G phone module 6.3 SIM 7 Local Network 7.1 Bluetooth 7.2 Wifi 7.3 USB Networking 8 Computing 8.1 CPU 8.1.1 Many functional blocks of the CPU 8.1.2 Chipset 8.2 Memory 8.2.1 Flash Memory 8.2.1.1 Internal 32GB eMMC 8.2.1.2 Internal 'OneNand' 256MB 8.2.1.3 External microSD card 8.2.2 RAM 9 Other hardware (needs merging into hierarchy above)

Audio

Software

Most of the audio on the N900 is handled by gstreamer and PulseAudio. See the API documentation on sound

Main Speakers

Earpiece

Headphones

The headphone amplifier is a TPA6130a2 manufactured by Texas Instruments.

Composite out

FM radio transmitter

FM radio receiver

Bluetooth audio

Video

The GPU is a SGX530 licensed from Imagination Technologies.

Display

Built in LCD

Composite out

Front camera (VGA)

Rear camera (5MP)

Rear camera autofocus

Rear camera LED flash

Rear camera warning light

Rear camera shutter

USB

USB socket

User interaction

Touchscreen

The touch screen controller is a TSC 2005.

Accelerometer

Switches

Lock Switch

Headset Switch

Jack Switch

Camera Button

Power Button

Volume control

Rear cover presence switch

Camera cover

Keyboard

Matrix keyboard connected to row[7:0] x col[7:0] dedicated matrixscanner IO at GAIA.

All QCOL traces and QROW7 trace are equipped with ESD protection against static discharge.

Each switch under a key is connected to one col and one row trace

(QCOL->	__7__	__ 6__	__5__	__4__	__3__	__ 2__	__1__	__0_)
QROW7:						VOL-	VOL+	I
QROW6:								U
QROW5:								Y
QROW4:		Shft	Fn	CTRL		Rght	Down	T
QROW3:	Left		SPC	M	N	B	V	R
QROW2:	C	X	Z		CR	Up	.	E
QROW1:	L	K	J	H	G	F	D	W
QROW0:	S	A		Del	,	P	O	Q

For example pressing W connects QCOL0 to QROW1.
The matrix controller applies a certain level (say +3V) to first col QCOL0 and checks which rows are going to same level (QROW1 for 'W'). Then next col is the one to get +3V, and so on.

For Shift-X QCOL6 will pull up QROW4 and QROW2. For Shift-T QCOL6 and QCOL0 will pull up QROW4.

Now the nasty part of it:
Shift-Fn-K means QCOL5 will pull up QROW4, and QCOL6 will pull up QROW4 and QROW1. BUT: when QROW4 is pulled high by QCOL5, then via the closed Shift key QROW4 will pull high QCOL6, and QCOL6 will pull high QROW1 via K switch. So the matrix controller will see QROW4 and QROW1 both be high, for either of QCOL5 and QCOL6, which looks like 4 keys shift, Fn, K, and(!) J are pressed. Situation for Shift-Fn-J is absolutely identical, and so Sh-Fn-J and Sh-Fn-K are not distinguishable.
for 3-key tupels the combinations are:
Sh-Fn-J/K
Sh-Fn-X/Z
Sh-CTL-K/H
Sh-CTL-A/Del
Fn-CTL-Space/M
Fn-CTL-J/H

Looking at this matrix, we notice two things:
1: Nokia missed to give real dedicated col-lines to the qualifier keys, though there would have been plenty, by simply arranging the keys in matrix in a smarter way. That would have completely avoided the above described N-key rollover issue
Another common method to fix this problem is to use diodes in series with the key switches. A diode for Ctrl, Shift, and Fn would be just enough here, adding to the BOM with only 3 parts a 2ct each.
2: U has its own row, and U is used for flashing (USB-flashing mode). Coincidence? Let's assume Nokia EE thought (for whatever weird reason) it might be clever to have a dedicated row for U (so they just pull high QCOL0 in NOLO bootloader and check the 8 row lines by reading in that byte). Then we might start to wonder what's with Y. And with I? And with T R W E Q? Nota bene press&hold multiple of those keys will always still deliver a nice clean easy-to-read 8bit result, on the presumed test during boot in NOLO

(p.s: maybe the rows are driven high - or even low - and the cols are the sensing inputs. I've not checked this, as it doesn't change anything in the basic function principle and neither changes the problem with N-key rollover. For the NOLO speculations it makes more sense to have inputs on rows and drivers on cols, though)

Keyboard Slide

Proximity sensor

Ambient Light Meter

Power management

Battery

Charge meter

Battery Charger

Gaia

CPU

Phone

GPS

2G/3G phone module

SIM

Local Network

Bluetooth

Wifi

USB Networking

Computing

CPU

Many functional blocks of the CPU

Chipset

Memory

Flash Memory

Internal 32GB eMMC

Internal 'OneNand' 256MB

External microSD card

RAM

Other hardware (needs merging into hierarchy above)

(Click on device for wiki page with more information)

Device	Model (Manufacturer)	Description	Driver
LED Controller	LP5523
Digital Audio Data Serial Interface	TLV320AIC3x

For those wanting to hack on the hardware drivers, the Maemo Kernel source code can be downloaded here:

http://repository.maemo.org/pool/fremantle/free/k/kernel/