N900 Hardware Subsystems - Revision history

sixwheeledbeast: Protected "N900 Hardware Subsystems": Excessive vandalism ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

sixwheeledbeast — Sat, 24 Mar 2018 23:45:44 GMT

Protected "N900 Hardware Subsystems": Excessive vandalism ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

← Older revision

Revision as of 23:45, 24 March 2018

sixwheeledbeast: Reverted edits by 93.124.84.147 (Talk) to last revision by joerg_rw

sixwheeledbeast — Sat, 24 Mar 2018 23:38:47 GMT

Reverted edits by 93.124.84.147 (Talk) to last revision by joerg_rw

← Older revision		Revision as of 23:38, 24 March 2018
Line 85:		Line 85:
	====Camera cover====		====Camera cover====

-	~~http~~:~~//achat~~-~~cialis~~-~~generique.net/ cialis pas her~~	+	===Keyboard===
-	~~http~~:~~//commandercialisgenerique~~.~~net/ acheter cialis generique~~	+	Matrix keyboard connected to row[7:0] x col[7:0] dedicated matrixscanner IO at GAIA.
-	~~http~~://~~comprar~~-~~cialis~~-~~generico.net~~/ ~~comprar cialis~~	+
-	~~http:~~//~~acquistarecialisitalia.net~~/ ~~cialis ricetta medica~~	+	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
		+
		+	{\| class="wikitable" border=1
		+	!(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.<br>
		+	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:<br>
		+	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.<br>
		+	for 3-key tupels the combinations are:<br>
		+	Sh-Fn-J/K<br>
		+	Sh-Fn-X/Z<br>
		+	Sh-CTL-K/H<br>
		+	Sh-CTL-A/Del<br>
		+	Fn-CTL-Space/M<br>
		+	Fn-CTL-J/H<br>
		+
		+	Looking at this matrix, we notice two things:<br>
		+	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<br>
		+	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.<br>
		+	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===		===Proximity sensor===

93.124.84.147: commander cialis generique

93.124.84.147 — Sat, 24 Mar 2018 18:11:49 GMT

commander cialis generique

← Older revision		Revision as of 18:11, 24 March 2018
Line 85:		Line 85:
	====Camera cover====		====Camera cover====

-	~~===Keyboard===~~	+	http://achat-cialis-generique.net/ cialis pas her
-	~~Matrix keyboard connected to row[7~~:~~0] x col[7:0] dedicated matrixscanner IO at GAIA.~~	+	http://commandercialisgenerique.net/ acheter cialis generique
-		+	http://comprar-cialis-generico.net/ comprar cialis
-	~~All QCOL traces and QROW7 trace are equipped with ESD protection against static discharge.~~	+	http://acquistarecialisitalia.net/ cialis ricetta medica
-		+
-	~~Each switch under a key is connected to one col and one row trace~~	+
-		+
-	~~{\| class="wikitable" border=1~~	+
-	~~!(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.<br>~~	+
-	~~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:<br>~~	+
-	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.<br>	+
-	~~for 3-key tupels the combinations are:<br>~~	+
-	~~Sh-Fn-J~~/~~K<br>~~	+
-	~~Sh-Fn-X~~/~~Z<br>~~	+
-	Sh-~~CTL~~-K/~~H<br>~~	+
-	~~Sh-CTL-A~~/~~Del<br>~~	+
-	~~Fn-CTL-Space~~/~~M<br>~~	+
-	~~Fn-CTL-J~~/~~H<br>~~	+
-		+
-	~~Looking at this matrix, we notice two things:<br>~~	+
-	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<br>	+
-	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.<br>	+
-	~~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===		===Proximity sensor===

joerg_rw: /* Keyboard */ table-ize

joerg_rw — Sun, 21 Aug 2016 18:09:55 GMT

Keyboard: table-ize

← Older revision		Revision as of 18:09, 21 August 2016
Line 91:		Line 91:

	Each switch under a key is connected to one col and one row trace		Each switch under a key is connected to one col and one row trace
-	~~<pre>~~	+
-	(QCOL-> ~~7 6 5 4 3 2 1 0~~)	+	{\| class="wikitable" border=1
-	QROW7: VOL- VOL+ I	+	!(QCOL->!! __7__ !! __ 6__ !! __5__ !! __4__ !! __3__ !! __ 2__ !! __1__ !! __0_)
-	QROW6: U	+	\|-
-	QROW5: Y	+	\|QROW7: \|\| \|\| \|\| \|\| \|\| \|\| VOL- \|\| VOL+ \|\| I
-	QROW4: Shft Fn CTRL Rght Down T	+	\|-
-	QROW3: Left SPC M N B V R	+	\|QROW6: \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| U
-	QROW2: C X Z CR Up . E	+	\|-
-	QROW1: L K J H G F D W	+	\|QROW5: \|\| \|\| \|\| \|\| \|\| \|\| \|\| \|\| Y
-	QROW0: S A Del , P O Q	+	\|-
-	~~</pre>~~	+	\|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.<br>		For example pressing W connects QCOL0 to QROW1.<br>
	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.		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.

188.195.163.148: /* Touchscreen */

188.195.163.148 — Sun, 05 Jan 2014 21:46:04 GMT

Touchscreen

← Older revision		Revision as of 21:46, 5 January 2014
Line 69:		Line 69:
	===Touchscreen===		===Touchscreen===

-	The touch screen controller is a TSC 2005.	+	The touch screen controller is a [http://www.ti.com/product/tsc2005 TSC 2005].

	===Accelerometer===		===Accelerometer===

joerg_rw: /* Keyboard */

joerg_rw — Fri, 15 Jul 2011 13:23:05 GMT

Keyboard

← Older revision		Revision as of 13:23, 15 July 2011
Line 119:		Line 119:
	Looking at this matrix, we notice two things:<br>		Looking at this matrix, we notice two things:<br>
	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<br>		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<br>
-	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.	+	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.<br>
	2: U has its own row, and U is used for flashing (USB-flashing mode). Coincidence?		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		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

joerg_rw: /* Keyboard */

joerg_rw — Fri, 15 Jul 2011 13:21:15 GMT

Keyboard

← Older revision		Revision as of 13:21, 15 July 2011
Line 88:		Line 88:
	Matrix keyboard connected to row[7:0] x col[7:0] dedicated matrixscanner IO at GAIA.		Matrix keyboard connected to row[7:0] x col[7:0] dedicated matrixscanner IO at GAIA.

-	All QCOL and QROW7 ~~traces~~ are ~~eqipped~~ with ESD protection against static discharge	+	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		Each switch under a key is connected to one col and one row trace
	<pre>		<pre>
Line 118:		Line 119:
	Looking at this matrix, we notice two things:<br>		Looking at this matrix, we notice two things:<br>
	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<br>		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<br>
		+	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?		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		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

89.27.110.196: Imagination Technologies is a fabless IP company.

89.27.110.196 — Mon, 09 Aug 2010 18:28:05 GMT

Imagination Technologies is a fabless IP company.

← Older revision		Revision as of 18:28, 9 August 2010
Line 30:		Line 30:
	==Video==		==Video==

-	The GPU is a SGX530 ~~manufactured by~~ Imagination Technologies.	+	The GPU is a SGX530 licensed from Imagination Technologies.

	===Display===		===Display===

joerg_rw: /* Keyboard */

joerg_rw — Sun, 08 Aug 2010 22:56:17 GMT

Keyboard

← Older revision		Revision as of 22:56, 8 August 2010
Line 118:		Line 118:
	Looking at this matrix, we notice two things:<br>		Looking at this matrix, we notice two things:<br>
	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<br>		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<br>
-	2: U has its own row, and U is used for flashing (USB-flashing mode). ~~Incidence~~?	+	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		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

joerg_rw: /* Keyboard */

joerg_rw — Thu, 05 Aug 2010 02:38:05 GMT

Keyboard

← Older revision		Revision as of 02:38, 5 August 2010
Line 120:		Line 120:
	2: U has its own row, and U is used for flashing (USB-flashing mode). Incidence?		2: U has its own row, and U is used for flashing (USB-flashing mode). Incidence?
	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		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====		====Keyboard Slide====