Talk:I2C Compass

2009-07-30T18:21:16Z

Drdeath: /* More accurate pricing info coming up */ typo

= Pre-Orders =
Pre-orders of anything are non-binding so far and are to evaluate interest by the community. Please sign your name in the appropriate section.
== PCB only ==

== DIY-Kit ==

== Ready-made module ==
*[[User:Kagee|Kagee]] 02:28, 27 July 2009 (UTC)
*--[[User:Glenn|Glenn]] 16:04, 28 July 2009 (UTC) 1-4 pieces (or PCB only or DIY-Kit or Ready-made module)

=Updates=
As I proceed through the project, updates on my progress will show up here
== Software Related ==
=== Userspace vs kernel module ===
Initial research in Linux I2C implementation (yes, believe it or not, I dived into this head-first without any prior knowledge of how linux i2c worked) revealed that besides direct kernel-space adressing, I2C devices can also be adressed from userspace via the device file system by means of the i2c-dev module. Since it will apparently be quite easy to actually bake together the contraption once I uncover a source of parts (which I haven't really looked into much so far), be ready to access the module from userspace for the time being, because actually writing a dedicated kernel module for the chip will definitely be the trickier part of the project. --[[User:Drdeath|Drdeath]] 00:14, 26 July 2009 (UTC)

==Hardware Related==
=== HMC6352 vs HMC5843 ===
The 6352 has the simpler peripheral circuitry, which means less space consumption, but is considerably bigger itself.
The 5843 is smaller on its own, but has the disadvantage of needing a rather big capacitor in the periphery, which will be as big as the chip itself. The real advantage of the 5843 is that is is 3-axis, meaning that the device will not need to be held horizontal for accurate measurements. Currently I am leaning heavily towards the 5843. initial experiments will have to show how we can pull off stuffing the (in comparison) monstrous capacitor into the space available and still have enough room for wiring and chip plus all the other little gadgets and gizmos that are needed to make the whole contraption work.--[[User:Drdeath|Drdeath]] 00:32, 26 July 2009 (UTC)
=== Major Drawback on the HMC5843 ===
While the 6352 is capable of returning measurements in angular degrees, the 5843 squaks nothing more than raw measurements in three dimensions. It appears I have let myself be misled by the assumption that the distinction between modules called "magnetic sensors" and modules called "digital compass" by Honeywell would be in the "compasses" having this built-in processing capability. Well, I was wrong, and don't ask me how the 5843 merits the presumptious title of "compass" since basicly it is no more than a glorified three-dimensional magnetometer. Actually it is more of a magnetic gyroscope than a compass. The major drawback in this is that I've never done any three-dimensional vector mathematics before, and it will remain to be seen wether or not I can manage to figure out how to create a magnetic heading from those three vectors passed by the chip. If I can pull it off, so far so good, if not, it is back to square one with the preliminary design considerations, and either biting the two-axis bullet or consider different chips. Which of course may or may not be available equally wholesale - or equally inexpensive.--[[User:Drdeath|Drdeath]] 04:41, 27 July 2009 (UTC)
:'''Minor Update'''
:It would maybe be possible to use the HMC6343, a highly integrated complete digital compass solution. Downside is that it is a real tight fit in the space available, and that - hold on to your skivvies - the price is roughly five times that of a 5843, or four times that of the vaunted 6352. Upside is it is really a cream-of-the-crop module that would turn the FR into a first-rate digital compass - but who needs that?

::Update on the Update: If anyone is actually interested in setting fire to piles of cash, contact me, I could at least hand you a PCB design. About access, well, there's userspace...--[[User:Drdeath|Drdeath]] 18:08, 30 July 2009 (UTC)

=== Data processing on HMC5843 ===
[[Image:magneto.png|thumb|520px|Diagram of 3-dimensional magnetometer heading calculation]]
After turning the problem over in my mind as well as conferring with several people more math-savy than yours truely, I can (quite literally) draw the following picture:

By multiplying the unit vectors with their respective scalars received from the sensor and vector adding them, we can generate a vector that points along the magnetic field lines. We then proceed by calculating that vector's angle with the y unit vector's orthogonal plane. It is intuitively clear that this plane is again orthogonal to the surface of the earth, as long as the sensor is not tilted sideways. For that simple reason, the angle of the magnetic vector towards the X-Z plane is the angle of deflection from north.

Note how the rotation of the coordinate system around the y-axis, or the up-down tilt of the device leaves the angle intact. That is why this method is infinitely superior to the alternative, projecting the angle into the x-y plane. This method would not be tilt-independent, because with increasing tilt, the magnetic sum vector is increasingly affected by the z scalar, which would, when projected into the x-y plane, cause the angle to open up.

That of course leaves sideways tilt to be considered. To determine this, the accelerometers might render good service. Also this does not even adress the problem of calibration. Concerning that, I happen to have a few ideas up my sleve, but those are still too half-baked to be expressed just yet. --[[User:Drdeath|Drdeath]] 23:49, 27 July 2009 (UTC)

This place really starts to turn into the main information counter, so it's about time I got it organized a bit.
Now I was promising more ideas in my last update, so here goes. It is still to early to tell details, but as far as I understand it, the magnetometer data might be used to determine the orientation of the device. As long as we stay far enough from the poles (Are there any Neo's at Admundsen-Scott Base?) the magnetic field lines lay (relatively) flat along the surface of the earth. That means, whichever of the three magnetometers creates the smallest scalar is closest to pointing up.

I'm thinking about implementing a calibration process which determines the orientation of the Neo that way and maps the three magnetometers to the three unit vectors so the most sensible output could be generated. As long as the orientation of the device isn't radically altered afterwards, the device should then be able to generate sane headings in almost every orientation, rotation and if I provide for a mechanism to provide sign usage, even upside down and face down. Now don't ask me where that makes any sense, but a driver should provide for as much flexibility as possible and leave the making of the sense to the application programmer.

The method falls apart however if the rotation of the device respective to the field lines is close to 45 degrees, either because of the tilt of the field lines themselves ( they only run parallel to the earth surface at the equator, everywhere else they point down to some degree or another), and/or an unfortunate rotation of the device is choosen. That is because in those cases, deciding which scalar is pointing closest to "up" might generate unreliable results. In effect that means we must provide for a way the user application can see the decision made and run it by the user, and if need be, override it so the device doesn't start putting out garbage data.

Also note that we (either the driver or the userspace application) can always get the accelerometers in on it to double-check our decision against gravity. That might actually not be such a bad idea, since that at least gets the tilt of the field lines out of the way. And if anyone ABSOLUTELY insists to tilting his/her device between maybe 40 and 50 degrees, a cross-reference between gravity vector, field line vector and if all else fails even lattitude will enable us to make a decision anyway. Unless of course that same someone insists on calibrating the sensor inside an accelerating vehicle, but then whenever you make something more idiot-proof, murphy's law inevitably improves on it's idiots... Well, last but not least let me say that those are all still quite half-baked concepts, but at least they are pretty sound half-baked concepts. Details to follow as I work them out. --[[User:Drdeath|Drdeath]] 22:30, 28 July 2009 (UTC)

== Pricing Updates ==
Supply of the HMC5843 is secured, digikey.com has them, and surprise! they are waaay cheaper than expected. Expect cost for the module and diy kit to be on the low end of the initial prediction, or maybe even a bit below!--[[User:Drdeath|Drdeath]] 01:30, 26 July 2009 (UTC)

=== Distribution Hubs to lower prices for everybody ===
One last idea before I turn in (it is past four am here): If enough pre-orders can be scraped together, we can all save money by having people in different countries handle the procurement/distribution of modules and PCBs for their area, thus eliminating the customs fees that would otherwise apply twice (once on me importing the modules into Germany, once more on you importing it to your country). Did I neglect to mention I'm gonna put PCB files and all public domain? Sloppy me. --[[User:Drdeath|Drdeath]] 02:20, 26 July 2009 (UTC)

PS: Even if I have the PCBs made (which is not the best idea since I am subject to VAT) a handfull of PCBs for a few Euros sent in a single package to a single adress are more likely to pass by the customs bloodhounds unnoticed than a constant stream of modules at 40+USD (or more likely 30+ taking into account the more recent developments but I'm not making promises).

=== More accurate pricing info coming up ===
I'm about to order a couple of samples for my experiments, after that I'll probably have more exact information about what taxes and customs duties apply. As soon as I come out of intensive care from the heart attack I'll have, I'll update the pricing section so you can get yours. --[[User:Drdeath|Drdeath]] 18:19, 30 July 2009 (UTC)

Talk:I2C Compass

2009-07-30T18:19:46Z

Drdeath: /* Pricing Updates */ About to order samples

= Pre-Orders =
Pre-orders of anything are non-binding so far and are to evaluate interest by the community. Please sign your name in the appropriate section.
== PCB only ==

== DIY-Kit ==

== Ready-made module ==
*[[User:Kagee|Kagee]] 02:28, 27 July 2009 (UTC)
*--[[User:Glenn|Glenn]] 16:04, 28 July 2009 (UTC) 1-4 pieces (or PCB only or DIY-Kit or Ready-made module)

=Updates=
As I proceed through the project, updates on my progress will show up here
== Software Related ==
=== Userspace vs kernel module ===
Initial research in Linux I2C implementation (yes, believe it or not, I dived into this head-first without any prior knowledge of how linux i2c worked) revealed that besides direct kernel-space adressing, I2C devices can also be adressed from userspace via the device file system by means of the i2c-dev module. Since it will apparently be quite easy to actually bake together the contraption once I uncover a source of parts (which I haven't really looked into much so far), be ready to access the module from userspace for the time being, because actually writing a dedicated kernel module for the chip will definitely be the trickier part of the project. --[[User:Drdeath|Drdeath]] 00:14, 26 July 2009 (UTC)

==Hardware Related==
=== HMC6352 vs HMC5843 ===
The 6352 has the simpler peripheral circuitry, which means less space consumption, but is considerably bigger itself.
The 5843 is smaller on its own, but has the disadvantage of needing a rather big capacitor in the periphery, which will be as big as the chip itself. The real advantage of the 5843 is that is is 3-axis, meaning that the device will not need to be held horizontal for accurate measurements. Currently I am leaning heavily towards the 5843. initial experiments will have to show how we can pull off stuffing the (in comparison) monstrous capacitor into the space available and still have enough room for wiring and chip plus all the other little gadgets and gizmos that are needed to make the whole contraption work.--[[User:Drdeath|Drdeath]] 00:32, 26 July 2009 (UTC)
=== Major Drawback on the HMC5843 ===
While the 6352 is capable of returning measurements in angular degrees, the 5843 squaks nothing more than raw measurements in three dimensions. It appears I have let myself be misled by the assumption that the distinction between modules called "magnetic sensors" and modules called "digital compass" by Honeywell would be in the "compasses" having this built-in processing capability. Well, I was wrong, and don't ask me how the 5843 merits the presumptious title of "compass" since basicly it is no more than a glorified three-dimensional magnetometer. Actually it is more of a magnetic gyroscope than a compass. The major drawback in this is that I've never done any three-dimensional vector mathematics before, and it will remain to be seen wether or not I can manage to figure out how to create a magnetic heading from those three vectors passed by the chip. If I can pull it off, so far so good, if not, it is back to square one with the preliminary design considerations, and either biting the two-axis bullet or consider different chips. Which of course may or may not be available equally wholesale - or equally inexpensive.--[[User:Drdeath|Drdeath]] 04:41, 27 July 2009 (UTC)
:'''Minor Update'''
:It would maybe be possible to use the HMC6343, a highly integrated complete digital compass solution. Downside is that it is a real tight fit in the space available, and that - hold on to your skivvies - the price is roughly five times that of a 5843, or four times that of the vaunted 6352. Upside is it is really a cream-of-the-crop module that would turn the FR into a first-rate digital compass - but who needs that?

::Update on the Update: If anyone is actually interested in setting fire to piles of cash, contact me, I could at least hand you a PCB design. About access, well, there's userspace...--[[User:Drdeath|Drdeath]] 18:08, 30 July 2009 (UTC)

=== Data processing on HMC5843 ===
[[Image:magneto.png|thumb|520px|Diagram of 3-dimensional magnetometer heading calculation]]
After turning the problem over in my mind as well as conferring with several people more math-savy than yours truely, I can (quite literally) draw the following picture:

By multiplying the unit vectors with their respective scalars received from the sensor and vector adding them, we can generate a vector that points along the magnetic field lines. We then proceed by calculating that vector's angle with the y unit vector's orthogonal plane. It is intuitively clear that this plane is again orthogonal to the surface of the earth, as long as the sensor is not tilted sideways. For that simple reason, the angle of the magnetic vector towards the X-Z plane is the angle of deflection from north.

Note how the rotation of the coordinate system around the y-axis, or the up-down tilt of the device leaves the angle intact. That is why this method is infinitely superior to the alternative, projecting the angle into the x-y plane. This method would not be tilt-independent, because with increasing tilt, the magnetic sum vector is increasingly affected by the z scalar, which would, when projected into the x-y plane, cause the angle to open up.

That of course leaves sideways tilt to be considered. To determine this, the accelerometers might render good service. Also this does not even adress the problem of calibration. Concerning that, I happen to have a few ideas up my sleve, but those are still too half-baked to be expressed just yet. --[[User:Drdeath|Drdeath]] 23:49, 27 July 2009 (UTC)

This place really starts to turn into the main information counter, so it's about time I got it organized a bit.
Now I was promising more ideas in my last update, so here goes. It is still to early to tell details, but as far as I understand it, the magnetometer data might be used to determine the orientation of the device. As long as we stay far enough from the poles (Are there any Neo's at Admundsen-Scott Base?) the magnetic field lines lay (relatively) flat along the surface of the earth. That means, whichever of the three magnetometers creates the smallest scalar is closest to pointing up.

I'm thinking about implementing a calibration process which determines the orientation of the Neo that way and maps the three magnetometers to the three unit vectors so the most sensible output could be generated. As long as the orientation of the device isn't radically altered afterwards, the device should then be able to generate sane headings in almost every orientation, rotation and if I provide for a mechanism to provide sign usage, even upside down and face down. Now don't ask me where that makes any sense, but a driver should provide for as much flexibility as possible and leave the making of the sense to the application programmer.

The method falls apart however if the rotation of the device respective to the field lines is close to 45 degrees, either because of the tilt of the field lines themselves ( they only run parallel to the earth surface at the equator, everywhere else they point down to some degree or another), and/or an unfortunate rotation of the device is choosen. That is because in those cases, deciding which scalar is pointing closest to "up" might generate unreliable results. In effect that means we must provide for a way the user application can see the decision made and run it by the user, and if need be, override it so the device doesn't start putting out garbage data.

Also note that we (either the driver or the userspace application) can always get the accelerometers in on it to double-check our decision against gravity. That might actually not be such a bad idea, since that at least gets the tilt of the field lines out of the way. And if anyone ABSOLUTELY insists to tilting his/her device between maybe 40 and 50 degrees, a cross-reference between gravity vector, field line vector and if all else fails even lattitude will enable us to make a decision anyway. Unless of course that same someone insists on calibrating the sensor inside an accelerating vehicle, but then whenever you make something more idiot-proof, murphy's law inevitably improves on it's idiots... Well, last but not least let me say that those are all still quite half-baked concepts, but at least they are pretty sound half-baked concepts. Details to follow as I work them out. --[[User:Drdeath|Drdeath]] 22:30, 28 July 2009 (UTC)

== Pricing Updates ==
Supply of the HMC5843 is secured, digikey.com has them, and surprise! they are waaay cheaper than expected. Expect cost for the module and diy kit to be on the low end of the initial prediction, or maybe even a bit below!--[[User:Drdeath|Drdeath]] 01:30, 26 July 2009 (UTC)

=== Distribution Hubs to lower prices for everybody ===
One last idea before I turn in (it is past four am here): If enough pre-orders can be scraped together, we can all save money by having people in different countries handle the procurement/distribution of modules and PCBs for their area, thus eliminating the customs fees that would otherwise apply twice (once on me importing the modules into Germany, once more on you importing it to your country). Did I neglect to mention I'm gonna put PCB files and all public domain? Sloppy me. --[[User:Drdeath|Drdeath]] 02:20, 26 July 2009 (UTC)

PS: Even if I have the PCBs made (which is not the best idea since I am subject to VAT) a handfull of PCBs for a few Euros sent in a single package to a single adress are more likely to pass by the customs bloodhounds unnoticed than a constant stream of modules at 40+USD (or more likely 30+ taking into account the more recent developments but I'm not making promises).

=== More accurate pricing info coming up ===
I'm about to order a couple of samples for my experiments, after that I'll probably have more exact information about what taxes and customs dues apply. As soon as I come out of intensive care from the heart attack I'll have, I'll update the pricing section so you can get yours. --[[User:Drdeath|Drdeath]] 18:19, 30 July 2009 (UTC)

2009-07-27T23:15:49Z

Drdeath: Diagram of the basics of magnetometer heading calculation

Diagram of the basics of magnetometer heading calculation

Talk:I2C Compass

2009-07-27T05:06:35Z

Drdeath:

= Pre-Orders =
Pre-orders of anything are non-binding so far and are to evaluate interest by the community. Please sign your name in the appropriate section.
== PCB only ==

== DIY-Kit ==

== Ready-made module ==
[[User:Kagee|Kagee]] 02:28, 27 July 2009 (UTC)

=Updates=
As I proceed through the project, updates on my progress will show up here
== Userspace vs kernel module ==
Initial research in Linux I2C implementation (yes, believe it or not, I dived into this head-first without any prior knowledge of how linux i2c worked) revealed that besides direct kernel-space adressing, I2C devices can also be adressed from userspace via the device file system by means of the i2c-dev module. Since it will apparently be quite easy to actually bake together the contraption once I uncover a source of parts (which I haven't really looked into much so far), be ready to access the module from userspace for the time being, because actually writing a dedicated kernel module for the chip will definitely be the trickier part of the project. --[[User:Drdeath|Drdeath]] 00:14, 26 July 2009 (UTC)
== HMC6352 vs HMC5843 ==
The 6352 has the simpler peripheral circuitry, which means less space consumption, but is considerably bigger itself.
The 5843 is smaller on its own, but has the disadvantage of needing a rather big capacitor in the periphery, which will be as big as the chip itself. The real advantage of the 5843 is that is is 3-axis, meaning that the device will not need to be held horizontal for accurate measurements. Currently I am leaning heavily towards the 5843. initial experiments will have to show how we can pull off stuffing the (in comparison) monstrous capacitor into the space available and still have enough room for wiring and chip plus all the other little gadgets and gizmos that are needed to make the whole contraption work.--[[User:Drdeath|Drdeath]] 00:32, 26 July 2009 (UTC)
=== Major Drawback on the HMC5843 ===
While the 6352 is capable of returning measurements in angular degrees, the 5843 squaks nothing more than raw measurements in three dimensions. It appears I have let myself be misled by the assumption that the distinction between modules called "magnetic sensors" and modules called "digital compass" by Honeywell would be in the "compasses" having this built-in processing capability. Well, I was wrong, and don't ask me how the 5843 merits the presumptious title of "compass" since basicly it is no more than a glorified three-dimensional magnetometer. Actually it is more of a magnetic gyroscope than a compass. The major drawback in this is that I've never done any three-dimensional vector mathematics before, and it will remain to be seen wether or not I can manage to figure out how to create a magnetic heading from those three vectors passed by the chip. If I can pull it off, so far so good, if not, it is back to square one with the preliminary design considerations, and either biting the two-axis bullet or consider different chips. Which of course may or may not be equally wholesale.--[[User:Drdeath|Drdeath]] 04:41, 27 July 2009 (UTC)
:'''Minor Update'''
:It would maybe be possible to use the HMC6343, a highly integrated complete digital compass solution. Downside is that it is a real tight fit in the space available, and that - hold on to your skivvies - the price is roughly five times that of a 5843, or four times that of the vaunted 6352. Upside is it is really a cream-of-the-crop module that would turn the FR into a first-rate digital compass - but who needs that?

== Pricing Update ==
Supply of the HMC5843 is secured, digikey.com has them, and surprise! they are waaay cheaper than expected. Expect cost for the module and diy kit to be on the low end of the initial prediction, or maybe even a bit below!--[[User:Drdeath|Drdeath]] 01:30, 26 July 2009 (UTC)

=== Distribution Hubs to lower prices for everybody ===
One last idea before I turn in (it is past four am here): If enough pre-orders can be scraped together, we can all save money by having people in different countries handle the procurement/distribution of modules and PCBs for their area, thus eliminating the customs fees that would otherwise apply twice (once on me importing the modules into Germany, once more on you importing it to your country). Did I neglect to mention I'm gonna put PCB files and all public domain? Sloppy me. --[[User:Drdeath|Drdeath]] 02:20, 26 July 2009 (UTC)

PS: Even if I have the PCBs made (which is not the best idea since I am subject to VAT) a handfull of PCBs for a few Euros sent in a single package to a single adress are more likely to pass by the customs bloodhounds unnoticed than a constant stream of modules at 40+USD (or more likely 30+ taking into account the more recent developments but I'm not making promises).

Talk:I2C Compass

2009-07-27T04:41:37Z

Drdeath: /* HMC6352 vs HMC5843 */

= Pre-Orders =
Pre-orders of anything are non-binding so far and are to evaluate interest by the community. Please sign your name in the appropriate section.
== PCB only ==

== DIY-Kit ==

== Ready-made module ==
[[User:Kagee|Kagee]] 02:28, 27 July 2009 (UTC)

=Updates=
As I proceed through the project, updates on my progress will show up here
== Userspace vs kernel module ==
Initial research in Linux I2C implementation (yes, believe it or not, I dived into this head-first without any prior knowledge of how linux i2c worked) revealed that besides direct kernel-space adressing, I2C devices can also be adressed from userspace via the device file system by means of the i2c-dev module. Since it will apparently be quite easy to actually bake together the contraption once I uncover a source of parts (which I haven't really looked into much so far), be ready to access the module from userspace for the time being, because actually writing a dedicated kernel module for the chip will definitely be the trickier part of the project. --[[User:Drdeath|Drdeath]] 00:14, 26 July 2009 (UTC)
== HMC6352 vs HMC5843 ==
The 6352 has the simpler peripheral circuitry, which means less space consumption, but is considerably bigger itself.
The 5843 is smaller on its own, but has the disadvantage of needing a rather big capacitor in the periphery, which will be as big as the chip itself. The real advantage of the 5843 is that is is 3-axis, meaning that the device will not need to be held horizontal for accurate measurements. Currently I am leaning heavily towards the 5843. initial experiments will have to show how we can pull off stuffing the (in comparison) monstrous capacitor into the space available and still have enough room for wiring and chip plus all the other little gadgets and gizmos that are needed to make the whole contraption work.--[[User:Drdeath|Drdeath]] 00:32, 26 July 2009 (UTC)
=== Major Drawback on the HMC5843 ===
While the 6352 is capable of returning measurements in angular degrees, the 5843 squaks nothing more than raw measurements in three dimensions. It appears I have let myself be misled by the assumption that the distinction between modules called "magnetic sensors" and modules called "digital compass" by Honeywell would be in the "compasses" having this built-in processing capability. Well, I was wrong, and don't ask me how the 5843 merits the presumptious title of "compass" since basicly it is no more than a glorified three-dimensional magnetometer. Actually it is more of a magnetic gyroscope than a compass. The major drawback in this is that I've never done any three-dimensional vector mathematics before, and it will remain to be seen wether or not I can manage to figure out how to create a magnetic heading from those three vectors passed by the chip. If I can pull it off, so far so good, if not, it is back to square one with the preliminary design considerations, and either biting the two-axis bullet or consider different chips. Which of course may or may not be equally wholesale.--[[User:Drdeath|Drdeath]] 04:41, 27 July 2009 (UTC)

== Pricing Update ==
Supply of the HMC5843 is secured, digikey.com has them, and surprise! they are waaay cheaper than expected. Expect cost for the module and diy kit to be on the low end of the initial prediction, or maybe even a bit below!--[[User:Drdeath|Drdeath]] 01:30, 26 July 2009 (UTC)

=== Distribution Hubs to lower prices for everybody ===
One last idea before I turn in (it is past four am here): If enough pre-orders can be scraped together, we can all save money by having people in different countries handle the procurement/distribution of modules and PCBs for their area, thus eliminating the customs fees that would otherwise apply twice (once on me importing the modules into Germany, once more on you importing it to your country). Did I neglect to mention I'm gonna put PCB files and all public domain? Sloppy me. --[[User:Drdeath|Drdeath]] 02:20, 26 July 2009 (UTC)

PS: Even if I have the PCBs made (which is not the best idea since I am subject to VAT) a handfull of PCBs for a few Euros sent in a single package to a single adress are more likely to pass by the customs bloodhounds unnoticed than a constant stream of modules at 40+USD (or more likely 30+ taking into account the more recent developments but I'm not making promises).

I2C Compass

2009-07-27T01:53:23Z

Drdeath:

== Announcement ==
I intend to build a I2C Compass module that fits into the cavity upwards the sim card holder and right of the battery.

'''That being said I'd like to explicitly state that everything said below is so far a mere ''' '''''brainstorm''''' '''and nothing more. I'm still evaluating feasibility and make''' ''''' no promises whatsoever!!!'''''

Further announcements and updates can be found on the discussion page.

===Benefits===
While the gps does provide heading information, it computes said by drawing a line between the current and last position generated. Thus it is obvious that the heading generated will
* a) Fall behind increasingly with tightness of turn
* b) Be increasingly jittery and inaccurate with decreasing forward speed, as the gps-inherent jitter will be more and more pronounced.
Therefore it is desirable to have a device installed which generates heading directly from the earth magnetic field instead of by comparison of position.

=== Limitations ===
Unlike the gps, the magnetic compass module is affected by magnetic variation. Also the module will be next to useless pending implementation of it's use by software ad hoc.

== Details ==
The module will most likely consist of a HMC6352 or preferably the 3-axis HMC5843 module on a tiny PCB.
The HMC6352 in principle does not need any additional periphery to function. If the nearby radio circuits should turn out to interfere with the compass function, the addition of two resistors and two capacitors may prove necessary, which should have ample room in the space available. The HMC5843 needs a little more periphery but it should still be manageable in the space available Connections will be made by soldering wires to the test points on top of the main FR PCB.

=== Caveats ===
*It is possible if unlikely that the compass module could itself throw interference into the gps module. In this case, a decoupling capacitor in the power circuit of the compass module may be necessary.
*It is possible that the shielding of the nearby gps and gsm modules renders the magnetic field unusable to a HMC6352, or that the HMC6352, even decoupled, emits interferrence that render either the GPS or the GSM unusable if mounted in that position, either of which would lead to the project having to be given up since there is no other place inside the casing where the chip could be mounted.

=== Request for Contributions ===
I would appreciate contributions in the form of software, especially patches to frontends and gpsd to have them make use of the module. I intend to try and write a module myself, but I don't make any promises yet. '''See first and next paragraph!'''

== Status ==
The module is currently in planning stage.
=== Next Step(s) ===
In that order
* Find out about how the i2c bus can be made use of in linux
* <strike>Find out if a kernel module exists for this chip</strike> I've checked and came up blank.
* Order one or more ICs for testing purposes
* Etch a test board
* If none exists, get started on the kernel module

== Purchase ==
The module is (obviously) not available for purchase yet.

''' Wether or not I proceed to production state with this project depends largely on expression of interest by the community. '''

=== Pricing ===
Please note that these are preliminary figures which may well go either up or down. I will try to find volume discount prices on ICs and post more accurate price/order count relations asap.
*The end price for the complete module will probably be in the range of 40-60 USD exc S/H.
*Bare PCBs will range in the area of 1.50 to 2.00 USD + S/H.
*DIY-Kits with IC and PCB will range between 30 and 50 USD depending on order count.

=== Minimum Order Count ===
Preliminary minimum order counts are in the range of 40 PCBs. Ordering less PCBs is uneconomical.
=== Pre-Order ===
Non-binding pre-order is open effective immediately in the discussion thread of this page.

== Links and Resources ==
[http://www.magneticsensors.com/datasheets/HMC5843.pdf HMC5843 Datasheet] 
[http://www.sparkfun.com/datasheets/Components/HMC6352.pdf HMC6352 Datasheet]

[[Category:Hardware]]

Talk:Gwaterpas

2009-07-26T22:37:59Z

Drdeath: /* troubleshooting */

really good!
thanks!
I will certainly use it in the future!(within an other apps..)

== icon and .desktop file ==

I have made a small icon for this app.
[[Image:Waterpas.png|left|thumb|100px|Waterpas]]
Tell me what you think about it - i'd be glad to see it as the app's default icon.

Here's what my /usr/share/applications/gwaterpas.desktop looks like:
Encoding=UTF-8
Name=Waterpas
Comment=3D sensor
Exec=gwaterpas
Icon=gwaterpas
Terminal=false
Type=Application
Categories=Utilities;Utility;
SingleInstance=true
StartupNotify=true

--[[User:Black Sliver|Black Sliver]] 17:25, 28 January 2009 (UTC)

Would be interesting to add resolution/accuracy informations to this wiki page.
-> what should be expected to be measurable (how many degrees)
-- cberger

== resolution/accuracy ==

I understand that applying a logarithmic conversion would be interesting. The linear behaviour is somewhat 'brute' in de range that really matters.
The linear behaviour makes it especially useful for easy sensor monitoring.

The jitter that exists on the input sensor did hold me from doing so. Taking averages might help.
Conclusion: I did not do this yet. Don't know which one to favor: speed or accuracy

--- Kurt Van Dijck

How long does it take to get one value? If you just take a *few* samples, the delay won't be that bad and the jitter will reduce a lot I think.

Btw. I'm going to add a [http://trac.shr-project.org/trac/attachment/wiki/Screenshots/Screenshot-1.png SHR/Illume-Button] to the icon and change the "main" gradient a bit, as soon as I have some time. Could you include both icons then (so it can be changes by a single char in the .desktop file)?

--[[User:Black Sliver|Black Sliver]] 13:55, 4 February 2009 (UTC)

I've noticed this time is not so predictable. I did not take a look in the driver, but when you rotate 90 deg suddenly, it takes a while before the next sample is ready. Maybe some averaging is done in the kernel

--- Kurt Van Dijck

==troubleshooting==
i used this program a lot on OM2008.12 and it worked great. since then i have moved to shr-testing. in the latest build [shr-testing-20090422] the app does not work. it will lanch if you use:
/usr/share/applications/gwaterpas.desktop
from
Categories=Utilities;
to
Categories=Utility;

but when running none of functions work. either it is not talking to the accelerometers or they are not talking to it. --[[User:Jerjozwik|Jerjozwik]] 00:18, 27 April 2009 (UTC)

I have the same problem since I upgraded a week ago, but I had no time to find out why it's not working anymore. I only see 2 possibilities: API changed oder Kernel bug.

--[[User:Black Sliver|Black Sliver]] 02:09, 27 April 2009 (UTC)

This does the trick:
<pre>
--- gwaterpas-0.3/main.cc_old 2009-05-10 17:30:13.000000000 +0200
+++ gwaterpas-0.3/main.cc 2009-05-10 17:38:47.000000000 +0200
@@ -253,6 +253,7 @@
case EV_SYN:
break;
case EV_REL:
+ case EV_ABS:
switch (lp->code) {
case REL_X:
s->raw.x = lp->value /-1e3;
</pre>

Looks like my kernel (2.6.29-rc3) reports accelerometer motion as EV_ABS.

--[[User:jasager|jasager]]

Hi,

could you please provide a patched version, because I have no develop enviroment?

--[[User:Midyr|Midyr]]
: is the version available for download patched yet? If not, please get with it, because I still have that problem, and I really could use that app if I just could --[[User:Drdeath|Drdeath]] 22:37, 26 July 2009 (UTC)

For SHR, the Pachage says, it depends on libfltk, but the correct name of the dependency should be fltk
so on SHR do a
opkg install fltk
before installing gwaterpas

--[[User:matzehuber|matzehuber]]

Wishlist - Hardware: Digital compass

2009-07-26T14:47:18Z

Drdeath:

{{Hardware Wishlist}}

A magnetometer or electronic compass measures the magnetic field. This could be used to orient maps to the terrain and to add an inertial rotation data to the accelerometer data. And of course as stand alone compass.

The idea is to add a 2 axis or 3 axis magnetometer/compass, this can be an extra sensor, but it also makes sense to replace one of the two planned accelerometers with a compass if the space couldn't be found.

Note: A project to create a digital compass exists: [[I2C Compass]]

==Uses==
*Stand alone compass, i.e. useful when GPS perception is low.
*Orient maps to the terrain, see [[Wishlist/Auto_Align_Map]]
*Show correct direction of GPS coordinates even if the device is rotated or not moving (when moving the direction could be obtained from the GPS movement).
*Inertial addition to the accelerometers, for this one see below for more information.
*Robots

[[Category:Hardware ideas]]

==Hardware parts==
*[http://www.ssec.honeywell.com/magnetic/hmc6352.html Honeywell's HMC6352 2-Axis Digital Integrated Compass], 6.5 x 6.5 x 1.5 mm, [[I2C]] interface, 2 axis magnetic sensor, maximum speed 20 Hz
*[http://www.akm.com/datasheets/ak8973_E-01.pdf AKM 3-Axis Electronic Compass], 4 x 4 x 0.7 mm, I2C interface, 3 axis magnetic sensor, also includes temperature sensor, maximum speed 10-80 Hz? (100 ms per measurement is possible (and draws 0.8 mA), one measurement takes 12.56 ms, so less isn't possible)
* [http://www.global.yamaha.com/news/2006/20060726.html Yamaha YAS529 Three-Axis Geomagnetic Sensor IC Chip] (2.0mm x 2.0mm x 1.0mm), I2C compatible. 4mA x 10ms per 3-axis measurement.
* [http://www.asahi-kasei.co.jp/asahi/en/news/2005/e060322.html Asahi Kasei Microsystems AK8976A] Three-Axis Geomagnetic Sensor + Three-Axis acceleration sensor + 8bit temperature sensor, I2C & SPI, (4.5 mm × 4.5 mm × 1) mm 6.7 mA sensor operation, 460 µA average with measurement at 100 ms intervals

A 3 axis magnetic sensor has advantages, the rotation data is also available when holding the device vertical, and the rotation data is 2D instead of just 1D (the third axis can be gotten from the accelerometer). Honneywell's sensor is a bit more integrated, it is able to calculate the heading itself and has a built in calibration mode. With the AKM this must be done in software, which shouldn't be a problem, and leaves space for improvements.

==Inertial rotation in combination with accelerometer(s)==
A digital compass makes a nice addition to the accelerometer, since the absolute rotation can then be measured in 3D.

===One accelerometer===
With one 3 axis accelerometer (the Wiimote has only one too) you have three inputs. There are 6 degrees of freedom, so it's underdetermined. If you make some assumptions you can sense the following:
*When not moving the acceleration is equal to the direction of the up vector, so that can be measured directly. This is for example the case when using the device as steering wheel.
*When not rotating, accelerations in all directions can be sensed, however some rotation is unavoidable, so you can not really rely on this situation.
*When rotating around some point, you can calculate the way you're moving if you know what speed you're moving. This is done with the centrifugal force formula g = v2/r. The speed can be calculated if the starting state was stationary and some assumptions on the path are made.
*More interesting than exact movements are maybe gestures like little jerks

===Second accelerometer===
A second accelerometer adds three inputs, but the overlap is very big, so it's still underdetermined. The following detectable movements are added:
*Better detection of fast rotations, especially around the Z axis (if the device isn't held vertically with the sensors above each other)
*Fast movements including a rotation are a bit more determined, for example when holding the device like a baseball bat or golf stick the radius can be calculated. Note that it's not likely to make movements like that with a phone, you probably want to see the screen. Also note that the radius isn't that important most of the time.

For developers it is probably easier to have one sensor at the centre of the device, less hassle, and current Wiimote developers could use the same techniques as with the Wiimote. But of course there are uses for a second accelerometer.

===Compass===
A compass adds also three inputs (or two if it's a 2 axis model), but this input only gives a direction, the length of the vector isn't very useful for most purposes. This direction does however give you the information to detect the following:
*Absolute rotation around Z axis, making possible:
**Map orientation.
**Photo camera orientation
**Shooting/pointing games with real 360 degree vision.
**Star catalogue, hold your phone as a window to the sky and see the names of constellations and planets. This could of course also be done for mountaintops and other landmarks.
**Virtual sundial.
*Rotation speed around the Z axis, at every possible way you can hold your phone, only not at 2500 Hz accelerometer rate.

==Notes==
*The compass sensor isn't nearly as fast as an accelerometer, but that doesn't have to be a big problem, since it is absolute, a relative sensor has to be sampled much faster to get good results. It would be nice if it's at least about 25 Hz, so the motion is fluid.
*The compass sensor should possibly not be placed very close near antennae, although I don't really know.
== See also ==
[[I2C Compass]]

[[Category:Accelerometer]]

Wish List - Hardware

2009-07-26T14:43:53Z

Drdeath: /* Digital compass */

This page details hardware features which some would like to go into future phones similar to the [[Neo1973]].

Related pages are:
*[[Wishlist - Hardware - Novel Devices]] - openmoko will run on a large number of devices in the future, some of which may be DVD players, cameras, or convergance devices.
*[[Wishlist:Unlikely]] - Hardware that is unlikely to appear in any Openmoko device, due to it being impossible to fabricate with near-term technology, or for other reasons.
*[[Wishlist:Accessories]] - Accessories that people would like, that connect easily to the phone - initially primarily for the Neo1973
*[[Wishlist:Expansion]] - add-ons to the phone, maybe involving hardware changes, and software and hardware protocols to implement these.
*[[CAD models]] - information about the open case models and how to manipulated them yourself in order create custom casings.

This page is rather long. Before adding a new idea, please read through this page and the above pages, to make sure your idea has not been suggested before.
==Battery==
{{Main|Wishlist/LiFePO4 Battery}}

==Processor==
===A FPGA===
A FPGA is a general purpose reconfigurable logic device.
See [[Wish List - Hardware:FPGA]] for more details.

===Samsung S3C2443===
*[http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2443&&ppmi=1427 Samsung S3C2443] Up to 533 MHz, can act as a USB 2.0 device.

==Internal Memory==
===RAM===
128MB Dedicated for open files, running software etc., not for storage, or 256MB at all would be really nice and enough for any future software. Using RAM as a swap in unix would significantly speed up the booting process. Approx. 10MB of ram is needed only. The rest, installed software, etc. can be used from ROM sources.

===ROM===
Enough to Hold O/S and a fair number of applications and their settings. Persistent Storage with XIP capability. About 128 MB.

===Storage===
An internal Micro SDHC should be used for users' files and additional software. Furthermore, user should be allowed to connect to an external USB memory and use it for either a storage or OS purposes.

==Wireless data networking==

===WiMAX support===
[http://en.wikipedia.org/wiki/Wimax WiMAX] is a high-speed data service, similar to wifi, though longer range and newer. Where service is available, this would complement WiFi. Unfortunately, unlike wifi, frequencies vary worldwide, so global usage may be complex. In South Korea, 2.3Ghz is available for WiMAX, known as WiBro. WiMAX Forum sets heart on 2.5 GHz for global use.
----
Two campuses of the University of California have just completed a deal with a WiMAX service provider to lease UC's ITFS/EBS spectrum to provide WiMAX in the SF Bay Area. Bidding was aggressive between Nextwave, Sprint-Nextel, and Clearwire. Other UC campuses have awarded other contracts throughout California to various of the three contenders. The point here is: these three companies are competing aggressively for spectrum in the 2.5-2.7 GHz range, and it's not limited to CA. At a National ITFS Association meeting in 2005, representatives from Intel said they would be ready to release a WiMAX chipset compatible with these frequencies in 2007, for inclusion in laptops. I assume the folks at [[FIC]] know much more about it that I do! Based on these and other clues, I think WiMAX is coming in the 2.5-2.7 GHz band in the near future... I'll be surprised if I do not see some offerings by early 2009.

-[[User:Tzf|Tzf]] 21:54, 24 November 2007 (CET)

===LTE support===
[http://en.wikipedia.org/wiki/3GPP_Long_Term_Evolution Long Term Evolution (LTE)] is a high-speed data service, similar to WiMax, but designed to be more compatible with existing GSM systems. While Sprint & Clearwire are currently testing WiMax deployment in the US, AT&T and Verizon appear to be in preference of LTE.

While the project is ongoing and general in scope, it has set itself some specific goals, many of which are oriented around upgrading UMTS to a so-called fourth generation mobile communications technology, essentially a wireless broadband Internet system with voice and other services built on top.

===Emerging Protocols===
*[http://en.wikipedia.org/wiki/Near_Field_Communication Near Field Communication] has a few centimeter range, useable for keys, ID badges, pairing bluetooth devices and similar uses. Mentioned in newer bluetooth and SD standards. (No products.)
*[http://en.wikipedia.org/wiki/ZigBee ZigBee] is designed for connecting sensors and switches in buildings, with many options including mesh networks and aggressive power saving compared to bluetooth. (Almost no products available.)
*The [http://en.wikipedia.org/wiki/ANT_%28network%29 ANT network] is for connecting worn devices. Similar to ZigBee, but much simpler and maybe lower power. ([http://www.thisisant.com/?section=9 Short list] of products.)

==Camera==

* A camera that can take reasonable quality video and pictures is something many want. Applications vary from simple snapping, to gesture interfaces, video conferencing, barcode reading, business card reading, healthcare, servicing, biometric identification, and more.
** Unlike stand-alone cameras, an Openmoko camera could integrate EXIF information from GPS, compass, and internet, making it far more valuable.

* Some people can't take cameras into work - a model without the camera, or some way of removing the camera would be useful or leave the camera chip in place and have a removable lens assembly and replacement backcover.
** Ability to a) cover the lens when not in use (to protect it and make it more obvious when you are NOT taking photos), and b) possible "lock" on camera use if a business is providing the phone to its employees. This way the phones are identical in hardware, making it cheaper to produce.
*See [[Hardware:Neo1973:Alternate_Cases:Camera | Alternate Cases:Camera]] for phone casing suggestions.

* See [[Wishlist:Camera]] for a more detailed wishlist.

==Display==
===Multitouch screen===

''Main article: [[Wishlist:Spell_weaving|Spell weaving]]''

See also [http://pogue.blogs.nytimes.com/2007/03/27/the-multi-touch-screen/ this page] containing a link to a video demonstration.

A history of multitouch implementations is [http://billbuxton.com/multitouchOverview.html here] ([http://google.com/search?q=cache:billbuxton.com/multitouchOverview.html google cache version])

*Use examples: [http://www.youtube.com/watch?v=UcKqyn-gUbY&mode=related&search= Multi-touch interface (from Adobe TED)], [http://www.youtube.com/watch?v=1ftJhDBZqss&mode=related&search= Multi Touch (new touchscreen technology)]

===Bigger and better screen===
2.8" widescreen (like in [http://etencorp.com E-ten] PDA/smartphones), or 3.5" widescreen (like in [http://www.expansys.ie/d.aspx?i=134944 Fujitsu Siemens LOOX N560]).

262k or 16.7M colurs for displaying images and especially videos.

OLED for better contrast, more rich colours, and less energy consumption.

Maybe the [http://www.sharpsme.com/Page.aspx/europe/en/part/LS037V7DW01/ LS037V7DW01] by Sharp could be a solution. It has nearly the same specs as the currently used, but 3,7" -- [[User:Wedge | Wedge]]

I'd recommend the
[http://www.beck-oled-lcd-tft-display.de/display-datenblatt/typ/tpo/TD035SHED1%20Product%20Specification%20Ver%200.0-112906.pdf TD035SHED1 (Chineese spec paper)] since it has the very same pinout as the current one. Eventually I'm going to create a new case, and will use that display. Alternately the
[http://www.beck-oled-lcd-tft-display.de/display-datenblatt/typ/tpo/TD043MGEB1_v0.4.pdf TD043MGEB1] would be a nice option. However it has 8 bits per channel, and not 6 like the current one, so we would need some adaptor board to connect it: Pull down resistors on the 2 lowermost bits of each channel, and connect the current signal lines to the uppermost bits. Or somehow get 8 bits per channel from the controller.
--[[User:Datenwolf|Datenwolf]] 12:06, 28 July 2008 (UTC)

===="Slightly" Larger Screen====
43mm x 57mm (2.8inch diagonal) is tiny. A 53mm x 71mm (3.5 inch diagonal) like on the TD035STEE1 would be a nice improvement. A widescreen format at about 53mm x 82.5mm instead of the 3:4 aspect ratio would be even cooler (if one could be found).

====Higher resolution screen====
The current Openmoko hardware has a screen of size 2.8" and resolution 640 x 480 (VGA).

See this LCD panel: http://www.engadget.com/2006/12/27/hitachi-does-800-x-480-display-for-phones/

At 2.9" it is almost exactly the same size as the current screen but has a wider 800 x 480 resolution (WVGA). This is the same resolution as in the Nokia N800 web browsing devices (but those devices have a bigger, lower DPI screen).

A display panel like this would enhance the phones's usability as a small computer, particularly for activities like web browsing, with an almost negligible affect on the size of the device. It would cause slightly increased battery drain though.

===Distance sensing touchscreen===
{{Main|Hardware:NearlyTouchScreen}}
TouchKo's (now Wacom Company Ltd.) spatial capacitive "touchscreen", can sense fingers at a small distance, so you do not get your display greasy, and can unlike some touchscreens, be operated with gloves.

===<s>Video acceleration</s>===
Hardware acceleration for video playback and 2D/3D accelleration will be present in [[Neo1973 GTA02]].

===EPD===
Or electronic paper display, EPD is used in many new devices such as the new Motorola motofone, sonys new e-reader and Irex's iliad. The technology provides thin, lightweight, power saving screens using new eink technology. This technology could cut the weight of the phone and its power usage. For more info see: [http://www.eink.com eink's website].

Pro: laserprinter like quality, glossy, very stable image, easy on the eyes. Electronics are similar to TFT. Very low power consumption.

Con: Black and grey only (like a newspaper, but glossy), although there were already color prototypes in 2005. low framerate (5fps). Can reflect light (like paper), backlight is impossible.

===Transreflective===
It would be nice to have (the option of) a transreflective display, which while being less bright, is readable without needing to power the backlight. Then again, it depends on how much power the backlight uses compared to everything else...

===Second Display===
A 32x32 OLED display possibly on the back for camera framing or on an edge so it can be viewed like a pager.
This could be used to display any number of alerts (from any installed software) the alerts could have a dynamic prioritisation which means during the work day a message from the boss has high priority but lower at home (could be GPS/Time controlled?) multiple alerts shrink the icons to a 3x3 grid higher priority messages get more space.

===Pico Projector===
[http://www.engadget.com/media/2006/02/digismartphone2.jpg Like the one shown here] or [http://www.youtube.com/watch?v=sT1mhSRichk (video example here)] new cellphones are now coming out with a small, low power projector. This can be used to show movies from your cell phone with 0.5m high image on a while wall for example...

Sample Video: http://www.youtube.com/watch?v=sT1mhSRichk

Sample Vendor/Product Info: http://www.dlp.com/tech/what.aspx

==Input devices==

===Tablet PC like pen input (Wacom Technology)===
The Wacom tablet protocol is openly documented, OSS drivers exist. Connection via UART or USB.
[http://www.wacom-components.com/english/technology/emr.html Wacom mobile technology]
[http://www.wacom-components.com/english/product/sensorboard.html Sensorboards]

Add a pen holder to the case, suitable for a pen [http://www.wacom-components.com/english/product/pen.html like the "Super Slim Pen" on this page]

===Regular phone keypad===
I really like the idea of this phone BUT it misses one
crucial feature - a simple keypad(like most other phones have).
I'd be basicaly happy with a mobile device with a 3-4" screen with a slide out keypad(in a similar way as the n95).

===No Dependence on Stylus===
The Neo's basic functionality should be completely usable without a stylus, Like the iPhone but with stylus use for precision work.

===QWERTY keyboard===
There should be a model that provides a Palm Treo type keyboard for messaging and internet interface. This would be best implemented in a phone casing with clamshell form factor which would give plenty of room for both button keys and screen area. Lets not just copy the iPhones onscreen data entry and make a phone that is a serious data interface device.

===A laser projection keyboard===
Similar to [http://www.thinkgeek.com/computing/input/8193/ this], except the device would be integrated into the phone itself. Setting the Neo up on a stand on a flat surface (perhaps a stand could be built into the back of the Neo itself, or into a case) would turn the Neo into a micro-laptop. There may be several issues with the inclusion of this technology, including patents, the space required to project the laser grids, and the power consumption. If possible, however, it would make text input a breeze.

===Just a few more Buttons===

2 buttons more, 3 buttons total, mounted sideways would be enough. You could use them for play/pause and loudness controll while the phone remains in your pocket (display locked, ...), reading mails, rss, ebooks,... without wasting display space and so on.

With 5 buttons in total you could possibly emulate a keyboard (2^5 = 32 combinations) for those who know how to play a flute. Useable onehanded, not wasting display space and faster than t9. (It's not faster than T9 - I've used this system with the microwriter agenda --[[User:Speedevil|Speedevil]] 00:00, 2 July 2007 (CEST)) Hopefully this is not patented already.

===D-Pad and Buttons===
*Adding a D-pad (to the bottom of the phone) and 2 to 4 buttons (to the top) would provide some tactile input controls, in addition to the touchscreen. They could be used as shortcut keys in the menu, or playback control when playing media. When the phone is held sideways, they can be used as games controls. (With touchscreen alone, gameplay options are limited)

Game buttons would be best on both sides of the screen. The larger the buttons, the better. 2x 4 buttons in up-down-left-right configuration + some extra buttons separately a bit lower on the device would be good for many for emulation games.

Here is a concept drawing of a possible neo1973 gaming version:
(This has a 4-way direction pad, 8 way may be better for gaming)
 
[[Image:Neogame90.jpg]]
 
Shoulder buttons would be a great addition, too. It would be interesting if there was a total 4 of them, one for every corner. It would make the phone very flexible for rotating and 2 to 6 players playing on one device.
 
:''Note'' : The [http://en.wikipedia.org/wiki/Tapwave_Zodiac Tapwave Zodiac] Palm PDA / Game console hybrid had a similar setup - with an analog stick on the left (also used for quick selection using a radial main menu when working as a PDA), 4 buttons on the right (also configurable for shortcuts when using the device as PDA), and 2 shoulder buttons. Also it had and still has an enthusiastic scene of homebrew development (almost any console emulator for PalmOS can also take advantage of the additional buttons and graphic power of the device). If we also take into account the success encountered by the [http://en.wikipedia.org/wiki/GP32 GP32] in the past and the [http://en.wikipedia.org/wiki/GP2X GP2X] currently on the homebrew scene, it's not unreasonable to plan a future Openmoko device with both a SmartPhone/PDA functionnality ''and'' hand-held console targeting homebrew development.

===Touch bigger than display===
If the sensing area of the touch covered the whole front of the phone, buttons could be emulated. Palm used this to have an input area next to the screen.

===Thumb keyboard or keyboard attachment accessory===
*Could be slide out or clamshell (hinge on long side) design with an external OLED. The keyboard should be protected when not in use.
*Could be a clip on keyboard that attaches to the serial port or communicates by bluetooth (not preferred for permanent keyboard users).
*Cheap clippable miniusb keyboard
*One of the layouts proposed in [[Hardware:Keyboards]]
* What about virtual keyboard? [[http://www.extremetech.com/article2/0,3973,539778,00.asp Keyboard]]

===Analogue Controllers===

====Trackball====
A trackball would provide an efficient mouse-like interface in a very compact package. As exemplified in the newer Blackberry® models.
Maybe instead an optical sensor as are used in mice could be used so that the whole phone can be moved over a surface just like a mouse. (It could function as a Bluetooth mouse for other devices like laptop computers: see [[Bluetooth_Support#Acting_as_HID_device]]. Adding one other two-axis analogue input (possibly just the screen) would make the Neo usable as a TrackPoint or scroll-and-tilt mouse.) The same sensor might be usable as a barcode reader.

====Analog Joystick====
A joystick, or [http://www.extremetech.com/article2/0,1697,1772689,00.asp Rollermouse]-like device would provide additional control, compared with touchscreen only.
*A standard [http://en.wikipedia.org/wiki/Pointing_stick pointing stick (ie. TrackPoint)] might serve well. As a fairly standard part, might they be quite inexpensive?

====Dual analogues====
Dual analogue controllers (one trackball or joystick above, one below the screen, most likely) might even be feasible. That might be overkill since the accelerometers or touchscreen can be used to provide a second analogue input. But it would be nice to have four axes of analogue control without having to tilt the screen away from you or partly cover it with your hand.

===TV/radio receiver===
[[Digital Television]], [[Digital Radio]] or even normal analogue TV/radio is widely available in the world, though unfortunately in various different forms. In markets where one standard is widespread, and hardware is suitable, it would be a great extension of the phone to a general entertainment device for when you're away from home. Multi standard devices would be ideal, but may not be small, low-power, or cheap.
A good start would be an FM tuner, since it's one of the most widely used formats of radio broadcasting in the world.

Here's a selection of chips, though it's not clear if the drivers are open source. http://www.sigmatel.com/products/portable/wireless/fmtuner.aspx#fragment-14
http://www.st.com/stonline/products/families/automotive/am_fm_tuners.htm

===<s>Accelerometer</s>===
'''Avaliable in GTA02'''

This enables the phone to sense which direction 'down' is, and to sense any movements the phone makes.

See [[Accelerometer Fundamentals]] for more information on accelerometers as they may be used in phones.

In some cases integrated gyroscopes may also be needed. A [[#Digital compass]] can even be of more use since it gives absolute rotation so slow rotations could also be measured. A 3D compass would be nicest, but a simple 2D compass already is a helpful addition to the accelerometers.

*[[Wishlist:3D Viewport|3D Viewport]]
*[[Wishlist:Computer Mouse|Computer Mouse]]
*[[Wishlist:Determine Position|Determine Position]]
*[[Wishlist:Dynamic Screen Orientation|Dynamic Screen Orientation]]
*Change media player playlist when jogging vs walking.
*<s>Attempt to use to stabilise any future camera.</s> While possible in theory the time required to process the accelerometer signals would cause to much latency, as that it could effectively be used for image stabilisation. You'd have to connect the acceleromters directly to the camera circuits.

===Side-Mounted Touch Strip===
Add a "touch strip" sensor onto the side of the phone which can be used to scroll. By having it on the side you can use your thumb to scroll comfortably while holding the phone one-handed. An 8-element capacitive sensor would work wonderfully and be easy to fab using either a Quantum QT411 (http://www.qprox.com/products/qslide_qt411.php) or Analog Devices AD7143 (http://www.analog.com/en/prod/0,2877,AD7143,00.html) controller. The Analog Devices chip seems better suited due to it's smaller allowable element size.
*With the AD7143 you can have an 8-element (128-position) 25mm long strip - Perfect!.
*With a few OLED screens beneath the strip it could be used as dynamic configurable buttons/alerts eg. zoom/flash/shutter with a camera application and SMS/Email/Voicemail alerts in standby

===Heart Rate Compatibility===

An RF interface to receive data from popular heart rate straps (Polar, Garmin, Sigma, Suunto, etc.). This would go along well with the existing GPS functionality and possible future Accelerometer functionality to make for a full-blown workout tool.

Software can be written to track heart rate along a running, cycling, skiing, swimming loop, to monitor max and min heart rate, to match heart rate data to GPS coordinates and print map data w/ relevant data.

Consider using the heart rate monitor from Zephyr tech. This communicates over bluetooth and has an SDK available.
http://www.zephyrtech.co.nz/products/consumer/hrm

===Digital compass===
A digital compass is useful for orienting maps to the terrain and other location/direction/orientation based applications (... is 300 meter that way) when the user is standing still (regardless of GPS reception) and for following a bearing when GPS reception is poor or speed is low. Also could be used to make the accelerometer data more exact.

A compass is also useful for tagging photographs with the correct direction (in addition to location) of the photo.

Very small [[I2C]] sensors like [http://www.ssec.honeywell.com/magnetic/hmc6352.html Honeywell's HMC6352 2-Axis Digital Integrated Compass] (6.5 x 6.5 x 1.5 mm) are very appropriate for this. Another option is the much smaller [http://www.global.yamaha.com/news/2006/20060726.html Yamaha YAS529 Three-Axis Geomagnetic Sensor IC Chip] (2.0mm x 2.0mm x 1.0mm).

*[[Wishlist/Auto Align Map]]

See [[Wishlist - Hardware: Digital compass]] for more information

See [[I2C Compass]] for an attempt at one

===Thermometer===
An electronic thermometer might become handy for some users.

There are very small [[I2C]] devices available, that could easily integrate to the existing bus. For example [http://focus.ti.com/docs/prod/folders/print/tmp100.html this one from ti].
(Could just be cheap and use the thermometer from the battery, thats how they did it in the nokia 5140's). Also is integrated in a barometer/altimeter like the SMD500 mentioned in [[Wish List - Hardware - Atmospheric]].
::But if you carry it in your pocket it is unlikely to show the correct air temperature anyway. [[User:AudriusA|AudriusA]] 17:12, 12 January 2008 (CET)

===Barometer and Variometer (Altimeter)===

A Barometer measures air pressure. This can be used to give weather information, and also as a variometer, to sense relative altitude. Variometers are commonly used in flying microlight and ultralight aircraft, to get accurate relative altitude.

These are also common on high end GPS units. This is a great feature for walkers as you can tell how far you have got on any ascent/decent.

See [[Wish List - Hardware - Atmospheric]] for more information.
::The GPS device [[Manually using GPS|outputs the altitude]] as well. This has been tested and works fine. [[User:AudriusA|AudriusA]] 21:44, 7 February 2008 (CET)
:::The precision of GPS altitude is very coarse in comparison with a pressure based altimeter, in the order of 10m for GPS vs 25cm for a altimeter [[User:PTT|PTT]] 10:39, 13 October 2008 (UTC)

===Finger print sensor===
A fingerprint sensor gives easy and fast access to the phone, could lock the touchscreen etc. An example of this device can be found at [http://www.sonystyle.com/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/USD/SY_BrowseCatalog-Start?CategoryName=cpu_VAIONotebookComputers_UX_Series&Dept=computers Sony UX17].

Most fingerprint sensors in the embedded market include a navigation mode, where they work similar to either a touch-stick or touch-pad of a laptop.

[http://www.fujitsu.com/downloads/MICRO/fma/formpdf/mbf320_fsfin.pdf Fujitsu] has a small strip like reader that has SPI and USB support.

===Barcode Scanner===
*less cpu intensive and more reliable than camera+ocr
*though, bluetooth-enabled readers are already available.

===Light Sensor===
Ability to sense ambient light, and act accordingly. i.e if it's 3am and LightValue<.1 then Ring Quietly.

It can be used to tune brightness of LCD automatically.

Can camera be used like light sensor? (when we have camera)

===A pluggable sensor module===
Give the option of a composite sensor module consisting of pressure, humidity, temperature and light sensors(if camera not present, which is the case), which will be pluggable to the phone and connected to the USB 1.1 port.

===Wheel===
A navigation wheel like on a sony/ericsson 810i would be nice.

The wheel could be mounted beside the headphone jack. In software, it would be appropriate for it to appear as a mouse wheel to applications. The wheel should also accept a press which emulates a middle mouse button click.

Uses for this include:
1. Scrolling lists, with middle button as click/open item.
2. Volume control while talking and in media player.
3. Scrolling pages

===Proximity Sensor===
Switch off backlight when you place the phone to your ear. Prevent accidental activation of speakerphone or other sounds when the phone is near the ear (prevent hearing damage). Possibly switch the speakerphone on or off automatically depending on if the phone is by your head or not.
:Automatically turning the speakerphone on/off sounds good, but to avoid disturbing others, for example in public, turning it on could be delayed so for example short looking at the display or putting it to the other ear doesn’t activate it. Additionally/alternatively the delay could be combined with/replaced by a orientation (or motion) sensor, so that it’s not activated when holding it upright, but only when it’s lying e. g. on a table.

=== Make ''all'' unlocking of phone, password protected===

When my (current non-neophone) phone is in my pocket and I have it locked, it sometimes accidentally unlocks itself since only two keystrokes in the correct order are necessary to unlock it. When it's unlocked and still in my pocket it sometimes calls someone without my knowledge. All phones I've seen today have a press-just-one-button bypass to answer an incoming call even when the phone is locked. I suggest making the locking mechanism let the user configure it so that the user has to enter a password even for answering incoming calls. The likeliness of the phone accidentally runbbing against my car keys, hitting a ten character long password, unlocking the phone without my knowledge and consent is low enough even for us most unlucky users.

==Expansion==
===Positioning of Buttons, Connections and ports===

Ideally any cable ports such as charging, USB, audio, docking should not get in the way of your hand or fingers when holding it in it's normal orientation. For the sake of SDIO cards an external SD slot should be on the top edge. IR for remote control software and ease of inter-device communication should be on the corner so that it is facing away from you for both orientations. Buttons obviously are positioned for finger control. An example of how '''not''' to do this would be the HTC Universal

===Storage===

====MMC/SD/SDIO slot (rather than?) miniSD or microSD====
*Cheaper, more durable cards in a widely accepted format.
*Much much larger storage capacity, [http://blog.scifi.com/tech/archives/2007/08/23/toshiba_unleash_1.html even 32GB]
*Cards are harder to lose
*Wider selection of accessories, including SDIO accessories.
*Make externally available so that larger length SDIO cards can be used (thinking about SDIO WLAN here)
*[http://en.wikipedia.org/wiki/Secure_Digital_card#SDHC SDHC] compatible. It seems to already have the right hardware for it - see [[Neo1973_Hardware#microSD-Card]].
See more on [http://wiki.openmoko.org/wiki/Wish_List#SD_Card_Slot Wish list - SD Card Slot]

====Two SD slots====
*Micro SDHC for /home partition. Keep like current design underneath SIM card
*Hot swappable externally accessible normal size SDHC/SDIO slot

=== Internal Communication Bus ===
*A standard and/or documented internal communication bus of some sort could simplify adding new hardware modules.
*Serial USB or I2C connector internal to case towards the top
*Several digital I/O pins that operate at TTL levels
*A few analogue I/O pins attached to a A/D converter
*Documentation of Debug board connector could provide some of this functionality.

I2C is used on the Neo with some details of resources already in use documented!
Please see [[I2C | Neo I2C Devices]] for more information & a list of devices & the addresses currently in use & documented for the Neo1973.

===Local Communication===

====USB====
* 5V Powered, to avoid having to carry around a hub for when you want to occasionally plug in a memory stick. Many powered hubs will not recognize a totally unpowered host. Provide a maximum current to drive a basic USB keyboard/memory stick/mouse/webcam/astrowebcam. This could be done by adding a small cheap power converter like the [http://www.national.com/pf/LM/LM2753.html LM2753]
* USB 2.0 (USB 1.1 is too slow to transfer data to the card, removing the card everytime from the phone isn't an option too, because it is placed under the battery)
* '''Standard type A socket''' for quick & easy insertion of memory sticks and all kind of devices. This type of connector is more robust to wear and tear compared to the type B socket which is more prone to break down.
* OTG, to be able connect usb keyboard like [http://www.mobile-review.com/pda/review/cherry-kb-en.shtml Cherry G84-4321 SUNRG]
* Bootable USB device emulation: the possibility to boot any computer on a bootable flagged partition of the transflash.
* Protection against incorrectly wired USB ports: some USB ports are wired incorrectly; if the +5V and GND are swapped, the device would get -5V when it's expecting +5V, which could burn some chips. A reverse-biased diode between +5V and GND, D+ and GND, D- and GND, and (if used) ID and GND, with a low enough forward voltage drop (to limite the negative voltages to what the chips can withstand), would protect the device by tripping the port's short circuit protection.
* 2 USB-Ports; one for acting as USB-host and one for acting as USB-device at same time.

====Wireless USB support====
[http://en.wikipedia.org/wiki/Wireless_USB Wireless USB] is the wireless version of USB offering data-rates up to 480 Mbit/s over short distances (<3 meter). Chipsets suitable for a phone are likely to take some time to be available.

====Bluetooth with A2DP====
Is the blue-tooth radio present in the phone A2DP compatible. If not, make it so.

Great for listening to music or watching a movie with full sound.

====SIR/FIR transceiver (Serial Infrared) / IR remote control====
*An infrared transceiver is cheap, small, and useful for sync with many laptops and mobile phones.
*Replace/emulate all IR-based remote controls used for your tv, vcr, etc on your neo cell phone.
** replaces multiple 'dumb' devices with a single intelligent device (your neo) that you will probably carry with you at all times anyway.
**Command sets should be retrieved from a database or learned from other less intelligent remote control devices with macros.
**reduces clutter, particularly in the living room.
**inceases the neo's practical status as an 'always-have' device.

Other uses.
*Detecting reflections from inside of a caddy, and switching from active mode.
*FIR would be a nice option, as it's some 40 times faster than SIR.

===Other===

====Video Out====
*Through a docking port
**S-Video/Composite Out
**DVI Out
**HDMI Out
**Display Port

==Output devices==

===LED===
*The Neo1973 GTA02 will have LEDs of some sort behind at least one button. [http://lists.openmoko.org/pipermail/community/2007-July/008458.html]
*A blinking LED would be a cheap, low power way to inform the user of new SMS/Email....
**An alternative to this would be for one small part of the LCD to be separately backlit.
**This requires the CPU and LCD to be somewhat active, to keep the LCD refreshed, but gives much more information.
**A Small OLED Screen could be used and display much more information than a LED with minimal power usage.

*For example a multicolor LED which pulses yellow for GSM/GPRS transmit, blue for Bluetooth/Wifi, green to indicate non-urgent information - missed call etc, red to indicate battery low or other urgent notices.

**The LED and button ideas could be combined: illuminated buttons.
**It must be possible to completely disable the LED to save power or other personal preferences.

=== Flashlight ===
For finding keys, or any other application. May also optionally pulse in time with ring, to make phone more visible.
This is really well done in Nokia 5500.

-I second this one. The most used feature in my Nokia 5140 after the calling and sms features is the flashlight. It's just one simple LED, but powerful enough to see with if it's really dark. If it ain't dark, you won't need the light anyway. :)

Also, Who hasn't lost their keys and opened up their cell phone to use as a flashlight?

=== FM transmitter ===
Small FM transmitter to output to car, and other nearby radios.

Fix the biggest flaw in the iPod before Apple does!

=== Infrared Transmitter w/ universal remote software ===
Infrared LED on top of device with universal remote software so you can control televisions, DVDs etc.
[http://www.novii.tv/ Here] is an example of universal remote software.

:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.

:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.

:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.

===HAC Compliance===
[http://quux.wiki.zoho.com/WhereAreHACphones.html Here] is some summary/discussion of how hearing aid compliance rules work in the US. Specifically it would be nice to see the phone include a [http://www.hearingresearch.org/Dr.Ross/telecoil_and_telephones.htm telecoil], which allows the phone to connect wirelessly to many standard hearing aids.

==Mobile Communication options==

===Generic Access Network / Unlicensed Mobile Access===
This technology requires cooperation from the cellular provider, but [http://en.wikipedia.org/wiki/Unlicensed_Mobile_Access UMA/GAN] is already offered by T-Mobile in the United States, and perhaps others in other countries. Allowing the user to roam from GSM to wifi, this technology can save the end user a significant amount of money, and also allow the user to deploy coverage where there was none before. There are only a few UMA capable phones currently, but it would be great if this could be made to work on a phase 2 type Openmoko device.

Note that this features requires more advanced access to the GSM modem.
Special messages needs to be exchanged with the network.

===Faster/better mobile connectivity.===
[http://en.wikipedia.org/wiki/Gsm GSM]/[http://en.wikipedia.org/wiki/GPRS GPRS] is at best slow. An incremental improvement would be a radio with [http://en.wikipedia.org/wiki/EDGE EDGE ] support. EDGE is an evolved GSM standard and, like GPRS, it operates on the same frequency as voice. This means a quad-band EDGE radio will have near-complete worldwide coverage.

[http://en.wikipedia.org/wiki/UMTS UMTS] - which is widespread in Europe and being deployed in the US, [http://en.wikipedia.org/wiki/HSDPA HSDPA] (asia) and any other mobile standards would be nice for faster data connectivity and coverage.
It is unlikely that all of these will be supported initially, but it is a goal. These faster standards operate in different frequencies from GSM/GPRS/EDGE. Which frequency exactly will depend on the carrier and country. For UMTS in the US, AT&T uses 850/1900 MHz but T-Mobile will use 2100/1700 MHz for example.

Until that goal is reached, it is likely that some phones will be brought out for various specific markets - Europe, Asia, US.

===Ability to use multiple SIMs/networks===
* External SIM sockets are widely available in China, a dual external socket would be a very good solution.
* [http://www.fonefunshop.co.uk/dualsim/digital.htm Dual SIM card kit] - two SIMs are trimmed and combined, software supportwould be needed, and both can't be used at once...
* Some networks support multiple numbers on one SIM. Unfortunately this won't allow split networks.
* A second/dual GSM module would allow full use of both sims at all times.
* As a hack, [[Bluetooth_powered_Multi-SIM_support | use another mobile via BT]].
** As many as three SIM slots would be genuinely useful, especially for a 3G phone - some 3G data tariffs are only available on data-only SIMs. A user could quite reasonably have one SIM for data, once SIM for his personal voice calls, and a third SIM for his business number.
* Dual SIM card support will be especially welcome by the women. They just love to talk on the phone.
* Save the contents from several SIM-cards to memory and simulate them.

===PMR446/FRS Radio===
* Include a PMR/FRS Radio.
* A two-way walkie talkie lets you use the phone to communicate with friends without requiring a GSM connection (crowded networks at festivals, at locations with no GSM coverage).

2 way talk over Sprint/Nextel/Boost networks if possible. At least the walkie talkie feature for sure. It's very annoying being at a lake with no service and can't call your friend in the other boat across the lake.

===[[DECT]]===
* Include a [[DECT]] GAP/CAT-iq transceiver so you can use your home and/or office PSTN line
** Ability to use Alcatel phonebook stuff (like provided by the eventphone.de phone equipment) would be very nice too

===[[SIP phone]]===
Make stripped down (and thus cheaper) version of the Neo1973 phone for use as a SIP phone. Remove GPS, GSM, accelerometers, stylus.

Addition of an centimeters-precise location system [http://en.wikipedia.org/wiki/Real_Time_Location_Systems RTLS] would be nice, as it will allow highly sensible indoor context detection. Imagine putting the phone next to your mirror (where you shave daily) and watch it automatically switch to news radio channel. Or put it next to your bed and see it automatically switch to "sleeping" mode, when only calls from predefined numbers are accepted.

=='''Casing'''==
See also: [[Alternate Neo1973 case designs]] for a list of cases being considered for design/manufacture by the community.

=== Generic Back Plate Connector ===
If the Neo had a few connectors below the back plate, it would be much easier to develop custom backplates. Connectors needed would be GND, Power-out, Power-in (for charging/expansion battery appliances), some bus (either USB or some other bus, maybe usb wouldn't be the best choice since having a backplate and an upstream connection at the same time might cause problems) and maybe some ID pins to discern battery/charger/generic expansion modules on hardware level
--[[User:DrDeath|DrDeath]] 10:39, 27 September 2008 (UTC)

=== [[Hardware:Neo1973:Alternate_Cases:Expansion_Module_Casing | Expansion Module Casing]] ===
Longer case (150-160mm+) with space in the top to put expansion modules, including test & hobby hardware. Would require use of a standard internal power & communications bus. Could be left empty with blank cover or house cameras, solar panels, a crank powered charger, special transmitters/recievers, or anything else imaginable.

[http://www.likeasecret.com/Neo1973/Neo1973-Exp.mov Neo1973 Expansion Module Quicktime rendering] 
[[Image:Neo1973-Exp.png]]

-mb make a bigger higher resolution screen and the hardware will still be the same size and the free runer bigger a in the free place make z sliding thing wich you would sell in many colour and if sb whants a camera hi can buy it in the sliding thing or he can just buy it blank for his own hard-ware this would be cool this sliding pice could have some cind of shape thet would fit and let you the most posibilities even you could make it covering some front of the phone so you could place a joystick and buttos in it. If you would need leds you would buy a blank cover drill it and it would be fine becous you wouldnt injury the mine case of the phone.

=== Expansion Back Casing ===
Replacement backs with additional features ranging from solar power, larger batteries, extra hardware, ...

===[[Hardware:Neo1973:Alternate_Cases:Expansion_Front_Casing|Expansion Front Casing]]===
Replacement fronts with e.g. extra buttons.

===Clamshell Casing===
The clamshell form factor is much preferred by many in that: 1) it provides more area for both screen and keypad 2) its easier for one handed use, the buttons arent crammed in the bottom of the casing 3) clamshell open up to provide longer distance to cover both ear and mouth so you dont have to shout in noisy areas to be heard because the speaker is up on the side of your face 4) clamshells protect the screen from scratches

=== Space efficient Lanyard ===
The hole at the bottom of the phone takes a lot of space. A [http://en.wikipedia.org/wiki/Kensington_Security_Slot Kensington Security Slot] could be used instead.

=== Rugged version ===
We need something you can drop from 4 feet in to a puddle of dirty water on construction site. Sunlight readable display, maybe aluminium case. The big ugly pseudo military version. What about a casing similar to the OLPC project's in terms of dust and waterproofing? I frequently have to answer the phone with hands dripping sea water and most phone's do not take kindly to that type of treatment. Also the accelerometers can be wired to a protection mechanism which suspends all processing/data activity in case of a (free) fall.

*Seconded. Would get one at once. please IP68 and with rubber coating.
*I support this too. Might make more sense as an accessory which you can snap/peel onto your phone however?
*I'm eager to see a ruggedized version, maybe even floatable.
*+1. No point in having an excellent phone/PDA-device, if you can't take it with you where ever you may go. I think this might work as an optional accessory case design, as a previous contributor mentioned.

=== Transparent ===
Make a transparent, see-through casing. Why do we need a closed casing for open hardware and open software? Show the world it is a truly Free/Open source phone.

That makes sense to me. I second that idea!
Me, too!

=== Blank ===
Even though the transparent case would work too, I would like to see a blank case of pure black or white so people could have the option of air-brushing,painting or even drawing on the case.

===Integrated solar charger===
Perhaps on one side there could be an integrated photovoltaic. It would be small, but might it be enough to charge the device. It could be integrated in an aesthetically pleasing fashion like [http://i.i.com.com/cnwk.1d/i/bto/20080523/solarboat.jpg this]... except, with a matching color. :)

===Custom look===
Provide a service which offers custom case design like [[Freerunner_Alternative_Case_Designs|this one]], see images below. Just upload two images, reposition them in an interactive website, submit credit card information and the custom case design with application manual will be shipped to you.

<gallery caption="Special casing" heights="100px">
Image:Special-casing-front.jpg|front
Image:Special-casing-back.jpg|back
</gallery>

==Misc==
===Battery Size/Standby Time===

Since the device will be ultimately running a wide selection of software on it the battery needs to be somewhat more robust and have a longer standby time than that of current phone's. At the moment I'm using a Moto (2 days before charging) or a Samsung (3 days before charging) and am not impressed with either phone's standby time, and I'm not using the phone's for anything but calls.

=== Dedicated Power / Charger Pinout ===

Having not yet seen a physical Neo device, I haven't been able to examine any of the IOs to see if there already is a dedicated power / charger input. However, I can imagine that it might be very tempting to have the device charge solely via USB. For any device that is capable of USB-host, that is a '''horrible''' idea, particularly when it's intended to be a mobile-komputing device.

Since the device is able to run in USB host mode, it might be a good idea to allow for an alternate power supply, if say, a USB keyboard was being used for several hours. Rather than drain the battery, one could just supply power via the wall outlet while still providing endless hours of USB-host enjoyment for those hard-coders on the go.

The main question is just deciding on where to take power from (or at all) if in USB-client mode and the power cable is inserted, but really, that's not too big of a deal and can be solved with very minimal circuitry. If 5V is detected on the power line, then the obvious place to get it from is there at any point in time.

This might sound extraneous at first, but when the device shuts down in the middle of an important USB file transfer, or right before that great piece of code was saved, you can bet that those users will be saying "Hmm... a separate power adapter would have really come in handy right now".

I suggest a tiny 3mm, dedicated +5V power input (something a la Nokia).

With the dedicated charger it would also be possible to use any standard USB device if
the phone recognized the external power and enabled 5v power when plugged in.

===Galileo/GLONASS/GPS receiver===
*A multi-standard satellite positioning module would be nice eventually, it does not seem to be near-term due to chipset availability problems. Galileo is the to be launched (2011) European positioning system. GLONASS is the already existing Russian one.

=== GPS antena ===
The current GPS device seems even dependent on weather and may not work in heavy rain or snow. It seems necessary to think how to improve the reliability. The small portable GPS antena may be an option.

===X10 RF Remote===
Many PC-based media centers are being equipped with an RF (433 MHz) / X10-based remote control. The [http://en.wikipedia.org/wiki/X10_(industry_standard) X10] protocol also facilitates home automation to control lamps, switches, etc.
The advantages of using RF for control instead of Infra-red this that it also works when furniture, walls, or doors are blocking the path between RF remote and the equipment or device. [http://www.lirc.org/ Lirc] supports X10-based RF remotes (but expects having an USB RF receiver attached to the media center).

===RFID tag/RFID Reader===
* Implementation/Cooperation with: [http://www.rfidguardian.org/ RFID-Guardian]
*An enable-able tag would be of use - for example being able to use the phone to open doors, or cars. Unfortunately, it's moderately hard to do secure programmable tags that are compatible with existing systems, for obvious reasons.
* Say you have RFID tags on your personal belongings: cellphone, keys... Neo could be programmed to remember the last recorded GPS location before it lost contact with the respective RFIDs. It'd be trivial to check where you left your cellphone, get directions from a map...or beep when the phone gets out of RFID range.

*I agree with this idea, a great idea and you have to do it (Jackcday)
*Or, a python script that use the accelerometers and rfid reader, so when the phone moves it checks for an rfid tag (that would be in the users pocket) and if it doesn't get a response it rings in full volume, or starts a tracking utility :))))
*A RFID reader would need an antenna loop which could probably be used for wireless docking or even charging

===NFC chip===
*A Near Field Communication chip, with this chip it will be possible to pay with your phone (like a credit card)in the near future, see [http://www.nokia.com/A4305081 Nokia]for details
*NXP is a chip fabricator which provides NFC chips [http://nxp.com NXP] direct link>> www.nxp.com/#/pip/cb=[type=product,path=/53420/53424]|pip=[pfp=53424][0] their chips also support the above RFID reading

===Less weight===
* Work on the weight of the Neo1973 and following devices. At the present time the Neo1973 is just a moderate / normal business or multimedia phone. The ordinary "user" may want something lighter. Take a look at the following table, that's the Neo1973 compared with other common business or multimedia phones.
{|border="1"
| Neo1973 || Fujitsu-Siemens LOOX N560 || E-Ten Glofiish X500+ || Sony Ericsson P990i || iPhone || Nokia E65
|-
| 184 g || 160 g || 146 g || 150 g || 135 g || 115 g
|-
|}

===Make it smaller===
* To stay within physical matters: Maybe the Neo1973 is also just a normal business/multimedia phone when looking at the size. It would be great the shrink it a bit. Especially the thickness of 18.5 mm could be worked on!

===Standard 3.5mm headphone jack===
The Neo1973 uses a 4-conductor 2.5mm jack for stereo headphones and a microphone. A 2.5mm jack is the most common for headsets.

There is an emerging convention used in the Nokia N800 and some other devices. A 4-conductor 3.5mm jack that can use a microphone with special headsets, but can also be used with off-the-shelf 3.5mm stereo headphones. Adapters to 2.5mm are of course available and this 3.5mm jack is much more robust.

Neglecting space limitations, multiple sockets - 2.5mm and 3.5mm would be nice. Probably not practical in a phone. Other expanded plugs might allow remote controls.

Other uses might be better met using bluetooth, or USB audio.

===Software should know of the jack status===
It should be possible for the OS to see if there is something connected to the audio jacks. That would avoid the embarrasing moments when you accidently pull out the headphones from the cell/laptop and whatever you were listening blares over the place at full volume. If OS can see, that the headphones were unplugged without turning off the audio, then it could pop up a warning that would allow to direct audio to internal speakers or turn it off. If the user would replug the headphones/speakers then the warning would dissapear as well.

===Laser Pointer===
Include a built in laser pointer. Everything is better with lasers.

Make it a green one <10mW so it won't be illegal in quite a few countries.

===Completely free hardware===
Consider selling one device with absolutely no non-free components in it, even if that means dropping the GSM support. I believe having one such device available would be good, because then it could be recommended by organizations like the FSF which typically never recommends anything if it has even a little non-free code in it.

=== Consider economy / inexpensive / less featured edition ===
Some people want less features, because they do not need them. Leaving out some features either lets the phone get smaller or possibly enhances battery live.

One big suggestion in this area is a b/w lower res display instead of the big color display.

=== Inductive Charger ===

It would be nice if it was possible to charge the phone without having to connect a cable. I'd like to have a simple docking station with an inductive charger like the type that's used for electric toothbrushes [http://home.howstuffworks.com/question292.htm ]. The charger itself could get its power from a standard wall-wart power supply, or it could be USB/Firewire powered.

==== Examples of existing commercial systems ====
* http://www.splashpower.com/

*might be combinable with a RFID reader

=== Solar panel/dynamo Charger===

It would be very nice to be able to charge the phone outside of the electric grid (for example on hikes and boating trips). A combined solar panel and muscle empowered (rotational etc.) charger would do the trick nicely.
* It might be possible to include a charger based on a step motor and an excentric weight, similar to automatic wrist watches. Charge by walking/running, if that wouldn't be cool...

'''some mobile Solarpanels'''

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=off01011&k_id=1400&hot=0 Off-Grid Systems Sunbag L]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=off01001&k_id=1400&hot=0 Off-Grid Systems Sunbag S]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sv_01011&k_id=1400&hot=0 Silva Solar I]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sv_01012&k_id=1400&hot=0 Silva Solar II]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sol01011&k_id=1400&hot=0 Solarc e-Go Professional] (link broken?)

[http://www.solarc.de/shop/product_info.php?info=p32_e-GO--Professional.html Solarc e-Go Professional] manufacturers page

[http://www.heise.de/mobil/suche/ergebnis?rm=result;q=solar;url=/mobil/artikel/74142/;words=solar Solarc e-Go *]

[http://www.heise.de/newsticker/suche/ergebnis?rm=result;words=Solar%20solar;q=solar;url=/newsticker/meldung/91536/ Solar JKT]

- I think a dynamo charger ("share charger", rotational, ...) would be more practical as a peripheral, connected through the USB-interface using the same principle cellphones now charge when connected to an USB-port. You could very easily hack this together. [http://www.metacafe.com/watch/449950/hack_a_flashlight_to_power_your/ flashlight recharge hack] Random thought; Why not create some merchandise toys with a small lithium battery which charge through centrifugal force allowing to recharge the phone with a small "general" connector.

[http://www.heise.de/mobil/artikel/61368/0 Article about aome mobile power-sources]

=== Plastic Solar/Back side on the Neo===

Solar cells from Plastic, on the reverse side of the Neo 1973
modified and introgreated in the battery backcover/flap,
like an energy source when the display is in standby mode.
Thats can be use also as alternate charge method's and also helps in emergency.

http://www.nanosolar.com/

=== Vibration===
Instead of using a counter-weighted motor to provide a vibrate function, a small solenoid could be used.It would provide more of a tap or click feel. It could be used to provide feedback when a on screen button is pressed. Different patterns of taps is a lot easier to recognize compared to different vibration frequencies. For those who know morse code they could have the phone tap out the phone number/name of the person calling/messaging or other alerts.

===As plug-in without screen...===

Along the lines of add-on cards, only looking at it from a different angle, I'd like to see a "faceless" openmoko with a documented hardware interface for both communicating with it and inserting it into other devices. Even the keypad/screen/battery would be attached, openmoko itself would just be faceless sliver of hardware with a documented interface and an API for communicating with the innards.

===Running without battery===
Please make it possible to run the device without a battery inserted (with the charger attached). I have several mobile phones which do not work anymore (even when attached to the charger) because the battery is worn out and new batteries are not available. I want the Openmoko to be usable when the battery is worn out.

* Seconded.

===Make GSM/CDMA/WiFi/WiMax/GPS plugable===
Please make Openmoko mobile as PC GSM/CDMA/... just working like plugable cards, they are cards/adaptor for the DEVICE only. the user may eject GSM module and inject with CDMA module. the DEVICE may provide several slot to allow user choose wifi/wimax/sd/gps/harddisk/...

===Wifi chip that can be used with kismet and other sniffers===
Please change the wifi chip that also can be used for sniffing wifi connection preferably the latest standard, not N. For pen testing. A wifi chips like the [http://www.ralinktech.com/ralink/data/RT2800.pdf RT2800] I think?

===Add a connector for an external Wifi aerial===
PLease can a an external aerial connector be added so better arials can be used useful for sniffing wifi connections for pen testing etc.

==Related Hardware==
See [[Related Hardware]]

[[Category:Hardware ideas| ]]

Wish List - Hardware

2009-07-26T14:43:17Z

Drdeath: /* Digital compass */

This page details hardware features which some would like to go into future phones similar to the [[Neo1973]].

Related pages are:
*[[Wishlist - Hardware - Novel Devices]] - openmoko will run on a large number of devices in the future, some of which may be DVD players, cameras, or convergance devices.
*[[Wishlist:Unlikely]] - Hardware that is unlikely to appear in any Openmoko device, due to it being impossible to fabricate with near-term technology, or for other reasons.
*[[Wishlist:Accessories]] - Accessories that people would like, that connect easily to the phone - initially primarily for the Neo1973
*[[Wishlist:Expansion]] - add-ons to the phone, maybe involving hardware changes, and software and hardware protocols to implement these.
*[[CAD models]] - information about the open case models and how to manipulated them yourself in order create custom casings.

This page is rather long. Before adding a new idea, please read through this page and the above pages, to make sure your idea has not been suggested before.
==Battery==
{{Main|Wishlist/LiFePO4 Battery}}

==Processor==
===A FPGA===
A FPGA is a general purpose reconfigurable logic device.
See [[Wish List - Hardware:FPGA]] for more details.

===Samsung S3C2443===
*[http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2443&&ppmi=1427 Samsung S3C2443] Up to 533 MHz, can act as a USB 2.0 device.

==Internal Memory==
===RAM===
128MB Dedicated for open files, running software etc., not for storage, or 256MB at all would be really nice and enough for any future software. Using RAM as a swap in unix would significantly speed up the booting process. Approx. 10MB of ram is needed only. The rest, installed software, etc. can be used from ROM sources.

===ROM===
Enough to Hold O/S and a fair number of applications and their settings. Persistent Storage with XIP capability. About 128 MB.

===Storage===
An internal Micro SDHC should be used for users' files and additional software. Furthermore, user should be allowed to connect to an external USB memory and use it for either a storage or OS purposes.

==Wireless data networking==

===WiMAX support===
[http://en.wikipedia.org/wiki/Wimax WiMAX] is a high-speed data service, similar to wifi, though longer range and newer. Where service is available, this would complement WiFi. Unfortunately, unlike wifi, frequencies vary worldwide, so global usage may be complex. In South Korea, 2.3Ghz is available for WiMAX, known as WiBro. WiMAX Forum sets heart on 2.5 GHz for global use.
----
Two campuses of the University of California have just completed a deal with a WiMAX service provider to lease UC's ITFS/EBS spectrum to provide WiMAX in the SF Bay Area. Bidding was aggressive between Nextwave, Sprint-Nextel, and Clearwire. Other UC campuses have awarded other contracts throughout California to various of the three contenders. The point here is: these three companies are competing aggressively for spectrum in the 2.5-2.7 GHz range, and it's not limited to CA. At a National ITFS Association meeting in 2005, representatives from Intel said they would be ready to release a WiMAX chipset compatible with these frequencies in 2007, for inclusion in laptops. I assume the folks at [[FIC]] know much more about it that I do! Based on these and other clues, I think WiMAX is coming in the 2.5-2.7 GHz band in the near future... I'll be surprised if I do not see some offerings by early 2009.

-[[User:Tzf|Tzf]] 21:54, 24 November 2007 (CET)

===LTE support===
[http://en.wikipedia.org/wiki/3GPP_Long_Term_Evolution Long Term Evolution (LTE)] is a high-speed data service, similar to WiMax, but designed to be more compatible with existing GSM systems. While Sprint & Clearwire are currently testing WiMax deployment in the US, AT&T and Verizon appear to be in preference of LTE.

While the project is ongoing and general in scope, it has set itself some specific goals, many of which are oriented around upgrading UMTS to a so-called fourth generation mobile communications technology, essentially a wireless broadband Internet system with voice and other services built on top.

===Emerging Protocols===
*[http://en.wikipedia.org/wiki/Near_Field_Communication Near Field Communication] has a few centimeter range, useable for keys, ID badges, pairing bluetooth devices and similar uses. Mentioned in newer bluetooth and SD standards. (No products.)
*[http://en.wikipedia.org/wiki/ZigBee ZigBee] is designed for connecting sensors and switches in buildings, with many options including mesh networks and aggressive power saving compared to bluetooth. (Almost no products available.)
*The [http://en.wikipedia.org/wiki/ANT_%28network%29 ANT network] is for connecting worn devices. Similar to ZigBee, but much simpler and maybe lower power. ([http://www.thisisant.com/?section=9 Short list] of products.)

==Camera==

* A camera that can take reasonable quality video and pictures is something many want. Applications vary from simple snapping, to gesture interfaces, video conferencing, barcode reading, business card reading, healthcare, servicing, biometric identification, and more.
** Unlike stand-alone cameras, an Openmoko camera could integrate EXIF information from GPS, compass, and internet, making it far more valuable.

* Some people can't take cameras into work - a model without the camera, or some way of removing the camera would be useful or leave the camera chip in place and have a removable lens assembly and replacement backcover.
** Ability to a) cover the lens when not in use (to protect it and make it more obvious when you are NOT taking photos), and b) possible "lock" on camera use if a business is providing the phone to its employees. This way the phones are identical in hardware, making it cheaper to produce.
*See [[Hardware:Neo1973:Alternate_Cases:Camera | Alternate Cases:Camera]] for phone casing suggestions.

* See [[Wishlist:Camera]] for a more detailed wishlist.

==Display==
===Multitouch screen===

''Main article: [[Wishlist:Spell_weaving|Spell weaving]]''

See also [http://pogue.blogs.nytimes.com/2007/03/27/the-multi-touch-screen/ this page] containing a link to a video demonstration.

A history of multitouch implementations is [http://billbuxton.com/multitouchOverview.html here] ([http://google.com/search?q=cache:billbuxton.com/multitouchOverview.html google cache version])

*Use examples: [http://www.youtube.com/watch?v=UcKqyn-gUbY&mode=related&search= Multi-touch interface (from Adobe TED)], [http://www.youtube.com/watch?v=1ftJhDBZqss&mode=related&search= Multi Touch (new touchscreen technology)]

===Bigger and better screen===
2.8" widescreen (like in [http://etencorp.com E-ten] PDA/smartphones), or 3.5" widescreen (like in [http://www.expansys.ie/d.aspx?i=134944 Fujitsu Siemens LOOX N560]).

262k or 16.7M colurs for displaying images and especially videos.

OLED for better contrast, more rich colours, and less energy consumption.

Maybe the [http://www.sharpsme.com/Page.aspx/europe/en/part/LS037V7DW01/ LS037V7DW01] by Sharp could be a solution. It has nearly the same specs as the currently used, but 3,7" -- [[User:Wedge | Wedge]]

I'd recommend the
[http://www.beck-oled-lcd-tft-display.de/display-datenblatt/typ/tpo/TD035SHED1%20Product%20Specification%20Ver%200.0-112906.pdf TD035SHED1 (Chineese spec paper)] since it has the very same pinout as the current one. Eventually I'm going to create a new case, and will use that display. Alternately the
[http://www.beck-oled-lcd-tft-display.de/display-datenblatt/typ/tpo/TD043MGEB1_v0.4.pdf TD043MGEB1] would be a nice option. However it has 8 bits per channel, and not 6 like the current one, so we would need some adaptor board to connect it: Pull down resistors on the 2 lowermost bits of each channel, and connect the current signal lines to the uppermost bits. Or somehow get 8 bits per channel from the controller.
--[[User:Datenwolf|Datenwolf]] 12:06, 28 July 2008 (UTC)

===="Slightly" Larger Screen====
43mm x 57mm (2.8inch diagonal) is tiny. A 53mm x 71mm (3.5 inch diagonal) like on the TD035STEE1 would be a nice improvement. A widescreen format at about 53mm x 82.5mm instead of the 3:4 aspect ratio would be even cooler (if one could be found).

====Higher resolution screen====
The current Openmoko hardware has a screen of size 2.8" and resolution 640 x 480 (VGA).

See this LCD panel: http://www.engadget.com/2006/12/27/hitachi-does-800-x-480-display-for-phones/

At 2.9" it is almost exactly the same size as the current screen but has a wider 800 x 480 resolution (WVGA). This is the same resolution as in the Nokia N800 web browsing devices (but those devices have a bigger, lower DPI screen).

A display panel like this would enhance the phones's usability as a small computer, particularly for activities like web browsing, with an almost negligible affect on the size of the device. It would cause slightly increased battery drain though.

===Distance sensing touchscreen===
{{Main|Hardware:NearlyTouchScreen}}
TouchKo's (now Wacom Company Ltd.) spatial capacitive "touchscreen", can sense fingers at a small distance, so you do not get your display greasy, and can unlike some touchscreens, be operated with gloves.

===<s>Video acceleration</s>===
Hardware acceleration for video playback and 2D/3D accelleration will be present in [[Neo1973 GTA02]].

===EPD===
Or electronic paper display, EPD is used in many new devices such as the new Motorola motofone, sonys new e-reader and Irex's iliad. The technology provides thin, lightweight, power saving screens using new eink technology. This technology could cut the weight of the phone and its power usage. For more info see: [http://www.eink.com eink's website].

Pro: laserprinter like quality, glossy, very stable image, easy on the eyes. Electronics are similar to TFT. Very low power consumption.

Con: Black and grey only (like a newspaper, but glossy), although there were already color prototypes in 2005. low framerate (5fps). Can reflect light (like paper), backlight is impossible.

===Transreflective===
It would be nice to have (the option of) a transreflective display, which while being less bright, is readable without needing to power the backlight. Then again, it depends on how much power the backlight uses compared to everything else...

===Second Display===
A 32x32 OLED display possibly on the back for camera framing or on an edge so it can be viewed like a pager.
This could be used to display any number of alerts (from any installed software) the alerts could have a dynamic prioritisation which means during the work day a message from the boss has high priority but lower at home (could be GPS/Time controlled?) multiple alerts shrink the icons to a 3x3 grid higher priority messages get more space.

===Pico Projector===
[http://www.engadget.com/media/2006/02/digismartphone2.jpg Like the one shown here] or [http://www.youtube.com/watch?v=sT1mhSRichk (video example here)] new cellphones are now coming out with a small, low power projector. This can be used to show movies from your cell phone with 0.5m high image on a while wall for example...

Sample Video: http://www.youtube.com/watch?v=sT1mhSRichk

Sample Vendor/Product Info: http://www.dlp.com/tech/what.aspx

==Input devices==

===Tablet PC like pen input (Wacom Technology)===
The Wacom tablet protocol is openly documented, OSS drivers exist. Connection via UART or USB.
[http://www.wacom-components.com/english/technology/emr.html Wacom mobile technology]
[http://www.wacom-components.com/english/product/sensorboard.html Sensorboards]

Add a pen holder to the case, suitable for a pen [http://www.wacom-components.com/english/product/pen.html like the "Super Slim Pen" on this page]

===Regular phone keypad===
I really like the idea of this phone BUT it misses one
crucial feature - a simple keypad(like most other phones have).
I'd be basicaly happy with a mobile device with a 3-4" screen with a slide out keypad(in a similar way as the n95).

===No Dependence on Stylus===
The Neo's basic functionality should be completely usable without a stylus, Like the iPhone but with stylus use for precision work.

===QWERTY keyboard===
There should be a model that provides a Palm Treo type keyboard for messaging and internet interface. This would be best implemented in a phone casing with clamshell form factor which would give plenty of room for both button keys and screen area. Lets not just copy the iPhones onscreen data entry and make a phone that is a serious data interface device.

===A laser projection keyboard===
Similar to [http://www.thinkgeek.com/computing/input/8193/ this], except the device would be integrated into the phone itself. Setting the Neo up on a stand on a flat surface (perhaps a stand could be built into the back of the Neo itself, or into a case) would turn the Neo into a micro-laptop. There may be several issues with the inclusion of this technology, including patents, the space required to project the laser grids, and the power consumption. If possible, however, it would make text input a breeze.

===Just a few more Buttons===

2 buttons more, 3 buttons total, mounted sideways would be enough. You could use them for play/pause and loudness controll while the phone remains in your pocket (display locked, ...), reading mails, rss, ebooks,... without wasting display space and so on.

With 5 buttons in total you could possibly emulate a keyboard (2^5 = 32 combinations) for those who know how to play a flute. Useable onehanded, not wasting display space and faster than t9. (It's not faster than T9 - I've used this system with the microwriter agenda --[[User:Speedevil|Speedevil]] 00:00, 2 July 2007 (CEST)) Hopefully this is not patented already.

===D-Pad and Buttons===
*Adding a D-pad (to the bottom of the phone) and 2 to 4 buttons (to the top) would provide some tactile input controls, in addition to the touchscreen. They could be used as shortcut keys in the menu, or playback control when playing media. When the phone is held sideways, they can be used as games controls. (With touchscreen alone, gameplay options are limited)

Game buttons would be best on both sides of the screen. The larger the buttons, the better. 2x 4 buttons in up-down-left-right configuration + some extra buttons separately a bit lower on the device would be good for many for emulation games.

Here is a concept drawing of a possible neo1973 gaming version:
(This has a 4-way direction pad, 8 way may be better for gaming)
 
[[Image:Neogame90.jpg]]
 
Shoulder buttons would be a great addition, too. It would be interesting if there was a total 4 of them, one for every corner. It would make the phone very flexible for rotating and 2 to 6 players playing on one device.
 
:''Note'' : The [http://en.wikipedia.org/wiki/Tapwave_Zodiac Tapwave Zodiac] Palm PDA / Game console hybrid had a similar setup - with an analog stick on the left (also used for quick selection using a radial main menu when working as a PDA), 4 buttons on the right (also configurable for shortcuts when using the device as PDA), and 2 shoulder buttons. Also it had and still has an enthusiastic scene of homebrew development (almost any console emulator for PalmOS can also take advantage of the additional buttons and graphic power of the device). If we also take into account the success encountered by the [http://en.wikipedia.org/wiki/GP32 GP32] in the past and the [http://en.wikipedia.org/wiki/GP2X GP2X] currently on the homebrew scene, it's not unreasonable to plan a future Openmoko device with both a SmartPhone/PDA functionnality ''and'' hand-held console targeting homebrew development.

===Touch bigger than display===
If the sensing area of the touch covered the whole front of the phone, buttons could be emulated. Palm used this to have an input area next to the screen.

===Thumb keyboard or keyboard attachment accessory===
*Could be slide out or clamshell (hinge on long side) design with an external OLED. The keyboard should be protected when not in use.
*Could be a clip on keyboard that attaches to the serial port or communicates by bluetooth (not preferred for permanent keyboard users).
*Cheap clippable miniusb keyboard
*One of the layouts proposed in [[Hardware:Keyboards]]
* What about virtual keyboard? [[http://www.extremetech.com/article2/0,3973,539778,00.asp Keyboard]]

===Analogue Controllers===

====Trackball====
A trackball would provide an efficient mouse-like interface in a very compact package. As exemplified in the newer Blackberry® models.
Maybe instead an optical sensor as are used in mice could be used so that the whole phone can be moved over a surface just like a mouse. (It could function as a Bluetooth mouse for other devices like laptop computers: see [[Bluetooth_Support#Acting_as_HID_device]]. Adding one other two-axis analogue input (possibly just the screen) would make the Neo usable as a TrackPoint or scroll-and-tilt mouse.) The same sensor might be usable as a barcode reader.

====Analog Joystick====
A joystick, or [http://www.extremetech.com/article2/0,1697,1772689,00.asp Rollermouse]-like device would provide additional control, compared with touchscreen only.
*A standard [http://en.wikipedia.org/wiki/Pointing_stick pointing stick (ie. TrackPoint)] might serve well. As a fairly standard part, might they be quite inexpensive?

====Dual analogues====
Dual analogue controllers (one trackball or joystick above, one below the screen, most likely) might even be feasible. That might be overkill since the accelerometers or touchscreen can be used to provide a second analogue input. But it would be nice to have four axes of analogue control without having to tilt the screen away from you or partly cover it with your hand.

===TV/radio receiver===
[[Digital Television]], [[Digital Radio]] or even normal analogue TV/radio is widely available in the world, though unfortunately in various different forms. In markets where one standard is widespread, and hardware is suitable, it would be a great extension of the phone to a general entertainment device for when you're away from home. Multi standard devices would be ideal, but may not be small, low-power, or cheap.
A good start would be an FM tuner, since it's one of the most widely used formats of radio broadcasting in the world.

Here's a selection of chips, though it's not clear if the drivers are open source. http://www.sigmatel.com/products/portable/wireless/fmtuner.aspx#fragment-14
http://www.st.com/stonline/products/families/automotive/am_fm_tuners.htm

===<s>Accelerometer</s>===
'''Avaliable in GTA02'''

This enables the phone to sense which direction 'down' is, and to sense any movements the phone makes.

See [[Accelerometer Fundamentals]] for more information on accelerometers as they may be used in phones.

In some cases integrated gyroscopes may also be needed. A [[#Digital compass]] can even be of more use since it gives absolute rotation so slow rotations could also be measured. A 3D compass would be nicest, but a simple 2D compass already is a helpful addition to the accelerometers.

*[[Wishlist:3D Viewport|3D Viewport]]
*[[Wishlist:Computer Mouse|Computer Mouse]]
*[[Wishlist:Determine Position|Determine Position]]
*[[Wishlist:Dynamic Screen Orientation|Dynamic Screen Orientation]]
*Change media player playlist when jogging vs walking.
*<s>Attempt to use to stabilise any future camera.</s> While possible in theory the time required to process the accelerometer signals would cause to much latency, as that it could effectively be used for image stabilisation. You'd have to connect the acceleromters directly to the camera circuits.

===Side-Mounted Touch Strip===
Add a "touch strip" sensor onto the side of the phone which can be used to scroll. By having it on the side you can use your thumb to scroll comfortably while holding the phone one-handed. An 8-element capacitive sensor would work wonderfully and be easy to fab using either a Quantum QT411 (http://www.qprox.com/products/qslide_qt411.php) or Analog Devices AD7143 (http://www.analog.com/en/prod/0,2877,AD7143,00.html) controller. The Analog Devices chip seems better suited due to it's smaller allowable element size.
*With the AD7143 you can have an 8-element (128-position) 25mm long strip - Perfect!.
*With a few OLED screens beneath the strip it could be used as dynamic configurable buttons/alerts eg. zoom/flash/shutter with a camera application and SMS/Email/Voicemail alerts in standby

===Heart Rate Compatibility===

An RF interface to receive data from popular heart rate straps (Polar, Garmin, Sigma, Suunto, etc.). This would go along well with the existing GPS functionality and possible future Accelerometer functionality to make for a full-blown workout tool.

Software can be written to track heart rate along a running, cycling, skiing, swimming loop, to monitor max and min heart rate, to match heart rate data to GPS coordinates and print map data w/ relevant data.

Consider using the heart rate monitor from Zephyr tech. This communicates over bluetooth and has an SDK available.
http://www.zephyrtech.co.nz/products/consumer/hrm

===Digital compass===
A digital compass is useful for orienting maps to the terrain and other location/direction/orientation based applications (... is 300 meter that way) when the user is standing still (regardless of GPS reception) and for following a bearing when GPS reception is poor or speed is low. Also could be used to make the accelerometer data more exact.

A compass is also useful for tagging photographs with the correct direction (in addition to location) of the photo.

Very small [[I2C]] sensors like [http://www.ssec.honeywell.com/magnetic/hmc6352.html Honeywell's HMC6352 2-Axis Digital Integrated Compass] (6.5 x 6.5 x 1.5 mm) are very appropriate for this. Another option is the much smaller [http://www.global.yamaha.com/news/2006/20060726.html Yamaha YAS529 Three-Axis Geomagnetic Sensor IC Chip] (2.0mm x 2.0mm x 1.0mm).

*[[Wishlist/Auto Align Map]]

See [[Wishlist - Hardware: Digital compass]] for more information
See [[I2C Compass]] for an attempt at one

===Thermometer===
An electronic thermometer might become handy for some users.

There are very small [[I2C]] devices available, that could easily integrate to the existing bus. For example [http://focus.ti.com/docs/prod/folders/print/tmp100.html this one from ti].
(Could just be cheap and use the thermometer from the battery, thats how they did it in the nokia 5140's). Also is integrated in a barometer/altimeter like the SMD500 mentioned in [[Wish List - Hardware - Atmospheric]].
::But if you carry it in your pocket it is unlikely to show the correct air temperature anyway. [[User:AudriusA|AudriusA]] 17:12, 12 January 2008 (CET)

===Barometer and Variometer (Altimeter)===

A Barometer measures air pressure. This can be used to give weather information, and also as a variometer, to sense relative altitude. Variometers are commonly used in flying microlight and ultralight aircraft, to get accurate relative altitude.

These are also common on high end GPS units. This is a great feature for walkers as you can tell how far you have got on any ascent/decent.

See [[Wish List - Hardware - Atmospheric]] for more information.
::The GPS device [[Manually using GPS|outputs the altitude]] as well. This has been tested and works fine. [[User:AudriusA|AudriusA]] 21:44, 7 February 2008 (CET)
:::The precision of GPS altitude is very coarse in comparison with a pressure based altimeter, in the order of 10m for GPS vs 25cm for a altimeter [[User:PTT|PTT]] 10:39, 13 October 2008 (UTC)

===Finger print sensor===
A fingerprint sensor gives easy and fast access to the phone, could lock the touchscreen etc. An example of this device can be found at [http://www.sonystyle.com/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/USD/SY_BrowseCatalog-Start?CategoryName=cpu_VAIONotebookComputers_UX_Series&Dept=computers Sony UX17].

Most fingerprint sensors in the embedded market include a navigation mode, where they work similar to either a touch-stick or touch-pad of a laptop.

[http://www.fujitsu.com/downloads/MICRO/fma/formpdf/mbf320_fsfin.pdf Fujitsu] has a small strip like reader that has SPI and USB support.

===Barcode Scanner===
*less cpu intensive and more reliable than camera+ocr
*though, bluetooth-enabled readers are already available.

===Light Sensor===
Ability to sense ambient light, and act accordingly. i.e if it's 3am and LightValue<.1 then Ring Quietly.

It can be used to tune brightness of LCD automatically.

Can camera be used like light sensor? (when we have camera)

===A pluggable sensor module===
Give the option of a composite sensor module consisting of pressure, humidity, temperature and light sensors(if camera not present, which is the case), which will be pluggable to the phone and connected to the USB 1.1 port.

===Wheel===
A navigation wheel like on a sony/ericsson 810i would be nice.

The wheel could be mounted beside the headphone jack. In software, it would be appropriate for it to appear as a mouse wheel to applications. The wheel should also accept a press which emulates a middle mouse button click.

Uses for this include:
1. Scrolling lists, with middle button as click/open item.
2. Volume control while talking and in media player.
3. Scrolling pages

===Proximity Sensor===
Switch off backlight when you place the phone to your ear. Prevent accidental activation of speakerphone or other sounds when the phone is near the ear (prevent hearing damage). Possibly switch the speakerphone on or off automatically depending on if the phone is by your head or not.
:Automatically turning the speakerphone on/off sounds good, but to avoid disturbing others, for example in public, turning it on could be delayed so for example short looking at the display or putting it to the other ear doesn’t activate it. Additionally/alternatively the delay could be combined with/replaced by a orientation (or motion) sensor, so that it’s not activated when holding it upright, but only when it’s lying e. g. on a table.

=== Make ''all'' unlocking of phone, password protected===

When my (current non-neophone) phone is in my pocket and I have it locked, it sometimes accidentally unlocks itself since only two keystrokes in the correct order are necessary to unlock it. When it's unlocked and still in my pocket it sometimes calls someone without my knowledge. All phones I've seen today have a press-just-one-button bypass to answer an incoming call even when the phone is locked. I suggest making the locking mechanism let the user configure it so that the user has to enter a password even for answering incoming calls. The likeliness of the phone accidentally runbbing against my car keys, hitting a ten character long password, unlocking the phone without my knowledge and consent is low enough even for us most unlucky users.

==Expansion==
===Positioning of Buttons, Connections and ports===

Ideally any cable ports such as charging, USB, audio, docking should not get in the way of your hand or fingers when holding it in it's normal orientation. For the sake of SDIO cards an external SD slot should be on the top edge. IR for remote control software and ease of inter-device communication should be on the corner so that it is facing away from you for both orientations. Buttons obviously are positioned for finger control. An example of how '''not''' to do this would be the HTC Universal

===Storage===

====MMC/SD/SDIO slot (rather than?) miniSD or microSD====
*Cheaper, more durable cards in a widely accepted format.
*Much much larger storage capacity, [http://blog.scifi.com/tech/archives/2007/08/23/toshiba_unleash_1.html even 32GB]
*Cards are harder to lose
*Wider selection of accessories, including SDIO accessories.
*Make externally available so that larger length SDIO cards can be used (thinking about SDIO WLAN here)
*[http://en.wikipedia.org/wiki/Secure_Digital_card#SDHC SDHC] compatible. It seems to already have the right hardware for it - see [[Neo1973_Hardware#microSD-Card]].
See more on [http://wiki.openmoko.org/wiki/Wish_List#SD_Card_Slot Wish list - SD Card Slot]

====Two SD slots====
*Micro SDHC for /home partition. Keep like current design underneath SIM card
*Hot swappable externally accessible normal size SDHC/SDIO slot

=== Internal Communication Bus ===
*A standard and/or documented internal communication bus of some sort could simplify adding new hardware modules.
*Serial USB or I2C connector internal to case towards the top
*Several digital I/O pins that operate at TTL levels
*A few analogue I/O pins attached to a A/D converter
*Documentation of Debug board connector could provide some of this functionality.

I2C is used on the Neo with some details of resources already in use documented!
Please see [[I2C | Neo I2C Devices]] for more information & a list of devices & the addresses currently in use & documented for the Neo1973.

===Local Communication===

====USB====
* 5V Powered, to avoid having to carry around a hub for when you want to occasionally plug in a memory stick. Many powered hubs will not recognize a totally unpowered host. Provide a maximum current to drive a basic USB keyboard/memory stick/mouse/webcam/astrowebcam. This could be done by adding a small cheap power converter like the [http://www.national.com/pf/LM/LM2753.html LM2753]
* USB 2.0 (USB 1.1 is too slow to transfer data to the card, removing the card everytime from the phone isn't an option too, because it is placed under the battery)
* '''Standard type A socket''' for quick & easy insertion of memory sticks and all kind of devices. This type of connector is more robust to wear and tear compared to the type B socket which is more prone to break down.
* OTG, to be able connect usb keyboard like [http://www.mobile-review.com/pda/review/cherry-kb-en.shtml Cherry G84-4321 SUNRG]
* Bootable USB device emulation: the possibility to boot any computer on a bootable flagged partition of the transflash.
* Protection against incorrectly wired USB ports: some USB ports are wired incorrectly; if the +5V and GND are swapped, the device would get -5V when it's expecting +5V, which could burn some chips. A reverse-biased diode between +5V and GND, D+ and GND, D- and GND, and (if used) ID and GND, with a low enough forward voltage drop (to limite the negative voltages to what the chips can withstand), would protect the device by tripping the port's short circuit protection.
* 2 USB-Ports; one for acting as USB-host and one for acting as USB-device at same time.

====Wireless USB support====
[http://en.wikipedia.org/wiki/Wireless_USB Wireless USB] is the wireless version of USB offering data-rates up to 480 Mbit/s over short distances (<3 meter). Chipsets suitable for a phone are likely to take some time to be available.

====Bluetooth with A2DP====
Is the blue-tooth radio present in the phone A2DP compatible. If not, make it so.

Great for listening to music or watching a movie with full sound.

====SIR/FIR transceiver (Serial Infrared) / IR remote control====
*An infrared transceiver is cheap, small, and useful for sync with many laptops and mobile phones.
*Replace/emulate all IR-based remote controls used for your tv, vcr, etc on your neo cell phone.
** replaces multiple 'dumb' devices with a single intelligent device (your neo) that you will probably carry with you at all times anyway.
**Command sets should be retrieved from a database or learned from other less intelligent remote control devices with macros.
**reduces clutter, particularly in the living room.
**inceases the neo's practical status as an 'always-have' device.

Other uses.
*Detecting reflections from inside of a caddy, and switching from active mode.
*FIR would be a nice option, as it's some 40 times faster than SIR.

===Other===

====Video Out====
*Through a docking port
**S-Video/Composite Out
**DVI Out
**HDMI Out
**Display Port

==Output devices==

===LED===
*The Neo1973 GTA02 will have LEDs of some sort behind at least one button. [http://lists.openmoko.org/pipermail/community/2007-July/008458.html]
*A blinking LED would be a cheap, low power way to inform the user of new SMS/Email....
**An alternative to this would be for one small part of the LCD to be separately backlit.
**This requires the CPU and LCD to be somewhat active, to keep the LCD refreshed, but gives much more information.
**A Small OLED Screen could be used and display much more information than a LED with minimal power usage.

*For example a multicolor LED which pulses yellow for GSM/GPRS transmit, blue for Bluetooth/Wifi, green to indicate non-urgent information - missed call etc, red to indicate battery low or other urgent notices.

**The LED and button ideas could be combined: illuminated buttons.
**It must be possible to completely disable the LED to save power or other personal preferences.

=== Flashlight ===
For finding keys, or any other application. May also optionally pulse in time with ring, to make phone more visible.
This is really well done in Nokia 5500.

-I second this one. The most used feature in my Nokia 5140 after the calling and sms features is the flashlight. It's just one simple LED, but powerful enough to see with if it's really dark. If it ain't dark, you won't need the light anyway. :)

Also, Who hasn't lost their keys and opened up their cell phone to use as a flashlight?

=== FM transmitter ===
Small FM transmitter to output to car, and other nearby radios.

Fix the biggest flaw in the iPod before Apple does!

=== Infrared Transmitter w/ universal remote software ===
Infrared LED on top of device with universal remote software so you can control televisions, DVDs etc.
[http://www.novii.tv/ Here] is an example of universal remote software.

:I'd like to add that i fully support this. An IR port on future openmoko devices capable of controlling set-top boxes like TV/DVD/Stereo is necessary to make the device as universal as possible. A cellphone should be your window to the world and allow you to interact with it in as many ways as possible.

:Care must be taken to use the correct type of IR chipset/controller in the phone. Most IR ports you find on devices like computers, some cellphones etc. Are for high speed data communication and CAN'T control TVs/DVDplayers/Stereos etc.

:In order to reduce cost it maybe possible to use the sound chipset in the phone to generate the waveform sent to the IR led. IR remotes work at ~38Khz which is within the range of the sound chipset. The sound output could be internally switched between the IR led or the speakers.

===HAC Compliance===
[http://quux.wiki.zoho.com/WhereAreHACphones.html Here] is some summary/discussion of how hearing aid compliance rules work in the US. Specifically it would be nice to see the phone include a [http://www.hearingresearch.org/Dr.Ross/telecoil_and_telephones.htm telecoil], which allows the phone to connect wirelessly to many standard hearing aids.

==Mobile Communication options==

===Generic Access Network / Unlicensed Mobile Access===
This technology requires cooperation from the cellular provider, but [http://en.wikipedia.org/wiki/Unlicensed_Mobile_Access UMA/GAN] is already offered by T-Mobile in the United States, and perhaps others in other countries. Allowing the user to roam from GSM to wifi, this technology can save the end user a significant amount of money, and also allow the user to deploy coverage where there was none before. There are only a few UMA capable phones currently, but it would be great if this could be made to work on a phase 2 type Openmoko device.

Note that this features requires more advanced access to the GSM modem.
Special messages needs to be exchanged with the network.

===Faster/better mobile connectivity.===
[http://en.wikipedia.org/wiki/Gsm GSM]/[http://en.wikipedia.org/wiki/GPRS GPRS] is at best slow. An incremental improvement would be a radio with [http://en.wikipedia.org/wiki/EDGE EDGE ] support. EDGE is an evolved GSM standard and, like GPRS, it operates on the same frequency as voice. This means a quad-band EDGE radio will have near-complete worldwide coverage.

[http://en.wikipedia.org/wiki/UMTS UMTS] - which is widespread in Europe and being deployed in the US, [http://en.wikipedia.org/wiki/HSDPA HSDPA] (asia) and any other mobile standards would be nice for faster data connectivity and coverage.
It is unlikely that all of these will be supported initially, but it is a goal. These faster standards operate in different frequencies from GSM/GPRS/EDGE. Which frequency exactly will depend on the carrier and country. For UMTS in the US, AT&T uses 850/1900 MHz but T-Mobile will use 2100/1700 MHz for example.

Until that goal is reached, it is likely that some phones will be brought out for various specific markets - Europe, Asia, US.

===Ability to use multiple SIMs/networks===
* External SIM sockets are widely available in China, a dual external socket would be a very good solution.
* [http://www.fonefunshop.co.uk/dualsim/digital.htm Dual SIM card kit] - two SIMs are trimmed and combined, software supportwould be needed, and both can't be used at once...
* Some networks support multiple numbers on one SIM. Unfortunately this won't allow split networks.
* A second/dual GSM module would allow full use of both sims at all times.
* As a hack, [[Bluetooth_powered_Multi-SIM_support | use another mobile via BT]].
** As many as three SIM slots would be genuinely useful, especially for a 3G phone - some 3G data tariffs are only available on data-only SIMs. A user could quite reasonably have one SIM for data, once SIM for his personal voice calls, and a third SIM for his business number.
* Dual SIM card support will be especially welcome by the women. They just love to talk on the phone.
* Save the contents from several SIM-cards to memory and simulate them.

===PMR446/FRS Radio===
* Include a PMR/FRS Radio.
* A two-way walkie talkie lets you use the phone to communicate with friends without requiring a GSM connection (crowded networks at festivals, at locations with no GSM coverage).

2 way talk over Sprint/Nextel/Boost networks if possible. At least the walkie talkie feature for sure. It's very annoying being at a lake with no service and can't call your friend in the other boat across the lake.

===[[DECT]]===
* Include a [[DECT]] GAP/CAT-iq transceiver so you can use your home and/or office PSTN line
** Ability to use Alcatel phonebook stuff (like provided by the eventphone.de phone equipment) would be very nice too

===[[SIP phone]]===
Make stripped down (and thus cheaper) version of the Neo1973 phone for use as a SIP phone. Remove GPS, GSM, accelerometers, stylus.

Addition of an centimeters-precise location system [http://en.wikipedia.org/wiki/Real_Time_Location_Systems RTLS] would be nice, as it will allow highly sensible indoor context detection. Imagine putting the phone next to your mirror (where you shave daily) and watch it automatically switch to news radio channel. Or put it next to your bed and see it automatically switch to "sleeping" mode, when only calls from predefined numbers are accepted.

=='''Casing'''==
See also: [[Alternate Neo1973 case designs]] for a list of cases being considered for design/manufacture by the community.

=== Generic Back Plate Connector ===
If the Neo had a few connectors below the back plate, it would be much easier to develop custom backplates. Connectors needed would be GND, Power-out, Power-in (for charging/expansion battery appliances), some bus (either USB or some other bus, maybe usb wouldn't be the best choice since having a backplate and an upstream connection at the same time might cause problems) and maybe some ID pins to discern battery/charger/generic expansion modules on hardware level
--[[User:DrDeath|DrDeath]] 10:39, 27 September 2008 (UTC)

=== [[Hardware:Neo1973:Alternate_Cases:Expansion_Module_Casing | Expansion Module Casing]] ===
Longer case (150-160mm+) with space in the top to put expansion modules, including test & hobby hardware. Would require use of a standard internal power & communications bus. Could be left empty with blank cover or house cameras, solar panels, a crank powered charger, special transmitters/recievers, or anything else imaginable.

[http://www.likeasecret.com/Neo1973/Neo1973-Exp.mov Neo1973 Expansion Module Quicktime rendering] 
[[Image:Neo1973-Exp.png]]

-mb make a bigger higher resolution screen and the hardware will still be the same size and the free runer bigger a in the free place make z sliding thing wich you would sell in many colour and if sb whants a camera hi can buy it in the sliding thing or he can just buy it blank for his own hard-ware this would be cool this sliding pice could have some cind of shape thet would fit and let you the most posibilities even you could make it covering some front of the phone so you could place a joystick and buttos in it. If you would need leds you would buy a blank cover drill it and it would be fine becous you wouldnt injury the mine case of the phone.

=== Expansion Back Casing ===
Replacement backs with additional features ranging from solar power, larger batteries, extra hardware, ...

===[[Hardware:Neo1973:Alternate_Cases:Expansion_Front_Casing|Expansion Front Casing]]===
Replacement fronts with e.g. extra buttons.

===Clamshell Casing===
The clamshell form factor is much preferred by many in that: 1) it provides more area for both screen and keypad 2) its easier for one handed use, the buttons arent crammed in the bottom of the casing 3) clamshell open up to provide longer distance to cover both ear and mouth so you dont have to shout in noisy areas to be heard because the speaker is up on the side of your face 4) clamshells protect the screen from scratches

=== Space efficient Lanyard ===
The hole at the bottom of the phone takes a lot of space. A [http://en.wikipedia.org/wiki/Kensington_Security_Slot Kensington Security Slot] could be used instead.

=== Rugged version ===
We need something you can drop from 4 feet in to a puddle of dirty water on construction site. Sunlight readable display, maybe aluminium case. The big ugly pseudo military version. What about a casing similar to the OLPC project's in terms of dust and waterproofing? I frequently have to answer the phone with hands dripping sea water and most phone's do not take kindly to that type of treatment. Also the accelerometers can be wired to a protection mechanism which suspends all processing/data activity in case of a (free) fall.

*Seconded. Would get one at once. please IP68 and with rubber coating.
*I support this too. Might make more sense as an accessory which you can snap/peel onto your phone however?
*I'm eager to see a ruggedized version, maybe even floatable.
*+1. No point in having an excellent phone/PDA-device, if you can't take it with you where ever you may go. I think this might work as an optional accessory case design, as a previous contributor mentioned.

=== Transparent ===
Make a transparent, see-through casing. Why do we need a closed casing for open hardware and open software? Show the world it is a truly Free/Open source phone.

That makes sense to me. I second that idea!
Me, too!

=== Blank ===
Even though the transparent case would work too, I would like to see a blank case of pure black or white so people could have the option of air-brushing,painting or even drawing on the case.

===Integrated solar charger===
Perhaps on one side there could be an integrated photovoltaic. It would be small, but might it be enough to charge the device. It could be integrated in an aesthetically pleasing fashion like [http://i.i.com.com/cnwk.1d/i/bto/20080523/solarboat.jpg this]... except, with a matching color. :)

===Custom look===
Provide a service which offers custom case design like [[Freerunner_Alternative_Case_Designs|this one]], see images below. Just upload two images, reposition them in an interactive website, submit credit card information and the custom case design with application manual will be shipped to you.

<gallery caption="Special casing" heights="100px">
Image:Special-casing-front.jpg|front
Image:Special-casing-back.jpg|back
</gallery>

==Misc==
===Battery Size/Standby Time===

Since the device will be ultimately running a wide selection of software on it the battery needs to be somewhat more robust and have a longer standby time than that of current phone's. At the moment I'm using a Moto (2 days before charging) or a Samsung (3 days before charging) and am not impressed with either phone's standby time, and I'm not using the phone's for anything but calls.

=== Dedicated Power / Charger Pinout ===

Having not yet seen a physical Neo device, I haven't been able to examine any of the IOs to see if there already is a dedicated power / charger input. However, I can imagine that it might be very tempting to have the device charge solely via USB. For any device that is capable of USB-host, that is a '''horrible''' idea, particularly when it's intended to be a mobile-komputing device.

Since the device is able to run in USB host mode, it might be a good idea to allow for an alternate power supply, if say, a USB keyboard was being used for several hours. Rather than drain the battery, one could just supply power via the wall outlet while still providing endless hours of USB-host enjoyment for those hard-coders on the go.

The main question is just deciding on where to take power from (or at all) if in USB-client mode and the power cable is inserted, but really, that's not too big of a deal and can be solved with very minimal circuitry. If 5V is detected on the power line, then the obvious place to get it from is there at any point in time.

This might sound extraneous at first, but when the device shuts down in the middle of an important USB file transfer, or right before that great piece of code was saved, you can bet that those users will be saying "Hmm... a separate power adapter would have really come in handy right now".

I suggest a tiny 3mm, dedicated +5V power input (something a la Nokia).

With the dedicated charger it would also be possible to use any standard USB device if
the phone recognized the external power and enabled 5v power when plugged in.

===Galileo/GLONASS/GPS receiver===
*A multi-standard satellite positioning module would be nice eventually, it does not seem to be near-term due to chipset availability problems. Galileo is the to be launched (2011) European positioning system. GLONASS is the already existing Russian one.

=== GPS antena ===
The current GPS device seems even dependent on weather and may not work in heavy rain or snow. It seems necessary to think how to improve the reliability. The small portable GPS antena may be an option.

===X10 RF Remote===
Many PC-based media centers are being equipped with an RF (433 MHz) / X10-based remote control. The [http://en.wikipedia.org/wiki/X10_(industry_standard) X10] protocol also facilitates home automation to control lamps, switches, etc.
The advantages of using RF for control instead of Infra-red this that it also works when furniture, walls, or doors are blocking the path between RF remote and the equipment or device. [http://www.lirc.org/ Lirc] supports X10-based RF remotes (but expects having an USB RF receiver attached to the media center).

===RFID tag/RFID Reader===
* Implementation/Cooperation with: [http://www.rfidguardian.org/ RFID-Guardian]
*An enable-able tag would be of use - for example being able to use the phone to open doors, or cars. Unfortunately, it's moderately hard to do secure programmable tags that are compatible with existing systems, for obvious reasons.
* Say you have RFID tags on your personal belongings: cellphone, keys... Neo could be programmed to remember the last recorded GPS location before it lost contact with the respective RFIDs. It'd be trivial to check where you left your cellphone, get directions from a map...or beep when the phone gets out of RFID range.

*I agree with this idea, a great idea and you have to do it (Jackcday)
*Or, a python script that use the accelerometers and rfid reader, so when the phone moves it checks for an rfid tag (that would be in the users pocket) and if it doesn't get a response it rings in full volume, or starts a tracking utility :))))
*A RFID reader would need an antenna loop which could probably be used for wireless docking or even charging

===NFC chip===
*A Near Field Communication chip, with this chip it will be possible to pay with your phone (like a credit card)in the near future, see [http://www.nokia.com/A4305081 Nokia]for details
*NXP is a chip fabricator which provides NFC chips [http://nxp.com NXP] direct link>> www.nxp.com/#/pip/cb=[type=product,path=/53420/53424]|pip=[pfp=53424][0] their chips also support the above RFID reading

===Less weight===
* Work on the weight of the Neo1973 and following devices. At the present time the Neo1973 is just a moderate / normal business or multimedia phone. The ordinary "user" may want something lighter. Take a look at the following table, that's the Neo1973 compared with other common business or multimedia phones.
{|border="1"
| Neo1973 || Fujitsu-Siemens LOOX N560 || E-Ten Glofiish X500+ || Sony Ericsson P990i || iPhone || Nokia E65
|-
| 184 g || 160 g || 146 g || 150 g || 135 g || 115 g
|-
|}

===Make it smaller===
* To stay within physical matters: Maybe the Neo1973 is also just a normal business/multimedia phone when looking at the size. It would be great the shrink it a bit. Especially the thickness of 18.5 mm could be worked on!

===Standard 3.5mm headphone jack===
The Neo1973 uses a 4-conductor 2.5mm jack for stereo headphones and a microphone. A 2.5mm jack is the most common for headsets.

There is an emerging convention used in the Nokia N800 and some other devices. A 4-conductor 3.5mm jack that can use a microphone with special headsets, but can also be used with off-the-shelf 3.5mm stereo headphones. Adapters to 2.5mm are of course available and this 3.5mm jack is much more robust.

Neglecting space limitations, multiple sockets - 2.5mm and 3.5mm would be nice. Probably not practical in a phone. Other expanded plugs might allow remote controls.

Other uses might be better met using bluetooth, or USB audio.

===Software should know of the jack status===
It should be possible for the OS to see if there is something connected to the audio jacks. That would avoid the embarrasing moments when you accidently pull out the headphones from the cell/laptop and whatever you were listening blares over the place at full volume. If OS can see, that the headphones were unplugged without turning off the audio, then it could pop up a warning that would allow to direct audio to internal speakers or turn it off. If the user would replug the headphones/speakers then the warning would dissapear as well.

===Laser Pointer===
Include a built in laser pointer. Everything is better with lasers.

Make it a green one <10mW so it won't be illegal in quite a few countries.

===Completely free hardware===
Consider selling one device with absolutely no non-free components in it, even if that means dropping the GSM support. I believe having one such device available would be good, because then it could be recommended by organizations like the FSF which typically never recommends anything if it has even a little non-free code in it.

=== Consider economy / inexpensive / less featured edition ===
Some people want less features, because they do not need them. Leaving out some features either lets the phone get smaller or possibly enhances battery live.

One big suggestion in this area is a b/w lower res display instead of the big color display.

=== Inductive Charger ===

It would be nice if it was possible to charge the phone without having to connect a cable. I'd like to have a simple docking station with an inductive charger like the type that's used for electric toothbrushes [http://home.howstuffworks.com/question292.htm ]. The charger itself could get its power from a standard wall-wart power supply, or it could be USB/Firewire powered.

==== Examples of existing commercial systems ====
* http://www.splashpower.com/

*might be combinable with a RFID reader

=== Solar panel/dynamo Charger===

It would be very nice to be able to charge the phone outside of the electric grid (for example on hikes and boating trips). A combined solar panel and muscle empowered (rotational etc.) charger would do the trick nicely.
* It might be possible to include a charger based on a step motor and an excentric weight, similar to automatic wrist watches. Charge by walking/running, if that wouldn't be cool...

'''some mobile Solarpanels'''

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=off01011&k_id=1400&hot=0 Off-Grid Systems Sunbag L]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=off01001&k_id=1400&hot=0 Off-Grid Systems Sunbag S]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sv_01011&k_id=1400&hot=0 Silva Solar I]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sv_01012&k_id=1400&hot=0 Silva Solar II]

[http://www.globetrotter.de/de/shop/detail.php?mod_nr=sol01011&k_id=1400&hot=0 Solarc e-Go Professional] (link broken?)

[http://www.solarc.de/shop/product_info.php?info=p32_e-GO--Professional.html Solarc e-Go Professional] manufacturers page

[http://www.heise.de/mobil/suche/ergebnis?rm=result;q=solar;url=/mobil/artikel/74142/;words=solar Solarc e-Go *]

[http://www.heise.de/newsticker/suche/ergebnis?rm=result;words=Solar%20solar;q=solar;url=/newsticker/meldung/91536/ Solar JKT]

- I think a dynamo charger ("share charger", rotational, ...) would be more practical as a peripheral, connected through the USB-interface using the same principle cellphones now charge when connected to an USB-port. You could very easily hack this together. [http://www.metacafe.com/watch/449950/hack_a_flashlight_to_power_your/ flashlight recharge hack] Random thought; Why not create some merchandise toys with a small lithium battery which charge through centrifugal force allowing to recharge the phone with a small "general" connector.

[http://www.heise.de/mobil/artikel/61368/0 Article about aome mobile power-sources]

=== Plastic Solar/Back side on the Neo===

Solar cells from Plastic, on the reverse side of the Neo 1973
modified and introgreated in the battery backcover/flap,
like an energy source when the display is in standby mode.
Thats can be use also as alternate charge method's and also helps in emergency.

http://www.nanosolar.com/

=== Vibration===
Instead of using a counter-weighted motor to provide a vibrate function, a small solenoid could be used.It would provide more of a tap or click feel. It could be used to provide feedback when a on screen button is pressed. Different patterns of taps is a lot easier to recognize compared to different vibration frequencies. For those who know morse code they could have the phone tap out the phone number/name of the person calling/messaging or other alerts.

===As plug-in without screen...===

Along the lines of add-on cards, only looking at it from a different angle, I'd like to see a "faceless" openmoko with a documented hardware interface for both communicating with it and inserting it into other devices. Even the keypad/screen/battery would be attached, openmoko itself would just be faceless sliver of hardware with a documented interface and an API for communicating with the innards.

===Running without battery===
Please make it possible to run the device without a battery inserted (with the charger attached). I have several mobile phones which do not work anymore (even when attached to the charger) because the battery is worn out and new batteries are not available. I want the Openmoko to be usable when the battery is worn out.

* Seconded.

===Make GSM/CDMA/WiFi/WiMax/GPS plugable===
Please make Openmoko mobile as PC GSM/CDMA/... just working like plugable cards, they are cards/adaptor for the DEVICE only. the user may eject GSM module and inject with CDMA module. the DEVICE may provide several slot to allow user choose wifi/wimax/sd/gps/harddisk/...

===Wifi chip that can be used with kismet and other sniffers===
Please change the wifi chip that also can be used for sniffing wifi connection preferably the latest standard, not N. For pen testing. A wifi chips like the [http://www.ralinktech.com/ralink/data/RT2800.pdf RT2800] I think?

===Add a connector for an external Wifi aerial===
PLease can a an external aerial connector be added so better arials can be used useful for sniffing wifi connections for pen testing etc.

==Related Hardware==
See [[Related Hardware]]

[[Category:Hardware ideas| ]]

User talk:Glenn

2009-07-26T03:21:16Z

Drdeath: /* I2C Compass */ new section

2009-07-26T00:15:25Z

Drdeath: /* Userspace vs kernel module */

= Pre-Orders =
Pre-orders of anything are non-binding so far and are to evaluate interest by the community. Please sign your name in the appropriate section.
== PCB only ==

== DIY-Kit ==

== Ready-made module ==

=Updates=
As I proceed through the project, updates on my progress will show up here
== Userspace vs kernel module ==
Initial research in Linux I2C implementation (yes, believe it or not, I dived into this head-first without any prior knowledge of how linux i2c worked) revealed that besides direct kernel-space adressing, I2C devices can also be adressed from userspace via the device file system by means of the i2c-dev module. Since it will apparently be quite easy to actually bake together the contraption once I uncover a source of parts (which I haven't really looked into much so far), be ready to access the module from userspace for the time being, because actually writing a dedicated kernel module for the chip will definitely be the trickier part of the project. --[[User:Drdeath|Drdeath]] 00:14, 26 July 2009 (UTC)

Talk:I2C Compass

2009-07-26T00:14:11Z

Drdeath:

= Pre-Orders =
Pre-orders of anything are non-binding so far and are to evaluate interest by the community. Please sign your name in the appropriate section.
== PCB only ==

== DIY-Kit ==

== Ready-made module ==

=Updates=
As I proceed through the project, updates on my progress will show up here
== Userspace vs kernel module ==
Initial research in Linux I2C implementation (yes, believe it or not, I dived into this head-first without any prior knowledge of how linux i2c worked) revealed that besides direct kernel-space adressing, I2C devices can also be adressed from userspace via the device file system by means of the i2c-dev module. Since it will apparently be quite easy to actually bake together the contraption once I uncover a source of parts (which I haven't really looked into much so far), be ready to access the module from userspace for the time being, because actually writing a dedicated module for the chip will definitely be the trickier part of the project. --[[User:Drdeath|Drdeath]] 00:14, 26 July 2009 (UTC)