Re: QVGA V/s VGA for GTA03 - product management, features & assumptions
I have used an iPhone, my wife's. The animations are pretty at first. After a while, they're just annoying. My wife gets impatient waiting for windows to get out of the way so she can get on with what she's trying to do. What's really funny is that some times the phone will do all that neat animation, and the window that shows up has no content. You stare at an empty contact list for as much as 3 seconds easily before it suddenly fills up with names. My wife may be an exception to the rule here. She sometimes does data entry at work and has the dialogs of her application memorized so she can type in the fields much faster than the application can keep up. When the keyboard beeps, she'll sit back and take a sip of her beverage while the application is popping dialogs up all over the place filling in what she typed. It's fun to watch. (FWIW: the application is running over a slow network via citrix, so it would take a lot to speed things up. She's stopped asking) With the touch screen UI, she can't use this approach. She has to wait. --Steve On Tue, Jun 10, 2008 at 2:13 PM, Stroller <[EMAIL PROTECTED]> wrote: > Reading these posts of the last few days it has just occurred to me > that it's not Carsten we should be beating up on here. > Who the heck asked for translucency and flashy animations? > > Management seem to be asking for this "alpha" bleeding rubbish, and > it seems to me that we users need to be telling management that we > don't care a heck for it. > > Sure, I know the iPhone does this now, but that doesn't mean Openmoko > has to do it. Do we really want Openmoko to be just another iPhone > clone? I know we see a fair number of posts on here about the iPhone, > but surely that's just a result of the current buzz - is UI animation > really a *necessity* in the long-term (or medium-term) future of the > mobile phone market? > > DISCLAIMER: I haven't used an iPhone, and I'm not terribly interested > in it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Landscape keyboard
On Mon, Jun 9, 2008 at 1:00 PM, Chris Wright <[EMAIL PROTECTED]> wrote: > ...The keyboard itself has very minimal needs in terms of resolution, but > it > steals about a third of the screen in portrait mode, more in landscape > -- 640x480 is probably a bare minimum. Chris's comment about the keyboard in landscape mode popped an image into my head. Maybe it's been mentioned already, but I don't recall. The keyboard for landscape mode could be split in two and have half on the right, and half on the left. I think that may make it more suitable for thumb typing and take less area away. Someone will probably ask me to mock it up, but I'm a HW guy, so you really don't want me to try :) --Steve M ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: resolution preferences??
This question is probably just because I misunderstood something you said before, but I'll ask anyway :) If it is acceptable to use QVGA, couldn't that basically be done without any hardware changes? I believe I remember you saying the glamo does scaling, so couldn't you let SW treat the display as qvga, and just have the glamo scale it up? Or, is the question more about having qvga instead of the glamo (which leaves you back with the SDIO interface shortage)? --Steve On Thu, Jun 5, 2008 at 10:42 PM, The Rasterman Carsten Haitzler < [EMAIL PROTECTED]> wrote: > On Thu, 05 Jun 2008 11:50:43 +0200 Marc Bantle <[EMAIL PROTECTED]> babbled: > > > > > quick question - would you prefer a qvga lcd (save a bit of cost) since > we'e > > > going to need to software-drive all graphics - the fewer pixels you > have to > > > fill, the better for speed. i'm really tossing up if the speed of qvga > is > > > worth the loss of resolution. i'm just not sure. > > > > > > > > Would that be 320x240 (QVGA [1]) or 480x320? > > qvga is 320x240. wqvga... that's a whole world of resolutions (400x240, > 432x240, 480x272, 480x320). :) > > > I think the latter would be acceptable in terms of usability. > > OTOH it would also > > but it's not a drop-in replacement as its widescreen. we c ould go for 2.8" > vga > or 2.8" qvga. drop-in replacement. anything else mans new case/design etc. > etc. > > also remember just getting supply of a screen is hard. you also need it at > a > decent physical size. > > i'm asking the question if going down to a (relatively) low resolution > screen > would be an ok compromise. > > > - create extra maintenance cost for system and app themes > > one way or another we will need to be able to do multiple resolutions in > the > long-run. > > > - narrow on-screen information for people with good eye-sight > > (granny won't be affected ;-) > > > > Sofar I haven't suffered from lacking graphic speed on my > > GTA01. It seemed that waiting for UI feedback was mainly > > cause by other background processes (e.g. SD-read or such) > > My interest are standard smartphone and geo apps and for > > those I'd rather go for resolution. > > again - it depends what you want to do. :) gta01 actually performance > better in > many ways graphically :) > > -- > Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: on screen keyboard enhaced
You could save quite a bit of room there by getting rid of a SHIFT and the
CAPS keys. you might consider something like a double-tap on shift locks
it, and a single tap only affects the next character.
--Steve
On Fri, May 30, 2008 at 12:30 PM, christooss <[EMAIL PROTECTED]> wrote:
> http://sudharsh.files.wordpress.com/2007/11/screenshot-1.png
>
> Here is a screenshot of one of onscreen keyboard. And I don't think its so
> small.
>
> And it could be bigger if special characters (&,$,€, {,} etc.) were hiden.
> Maybe a gesture that startes at part of the screen gets you to special
> characters.
>
> I will try this in this weekend. Just mockup app. And than actual porting.
>
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: picking up voicemail
Hmmm, the two would seem to counteract each other. (not displaying, but remembering it for you) I would be happy if it acted like my office phone does. It only displays, and re-dials, the actual phone number, and nothing after that. This is easy to do on a cell phone. Display the number typed in before "SEND" is pressed, then don't display anymore numbers. I wouldn't want anything I type after the phone number to be remembered for me. This information may be: * Credit card number * bank account number and pin * voicemail pin for any other system you use. On Mon, May 19, 2008 at 12:22 PM, Steven Kurylo <[EMAIL PROTECTED]> wrote: > On Sun, May 18, 2008 at 6:34 PM, Ian Darwin <[EMAIL PROTECTED]> wrote: > > There ought to be a specialization of Dialer to be able to type your > > voicemail password without having it echo, switchable dynamically. > > > > Just an idea - my son was complaining that his cheap Nokia didn't have > > such a feature, so I figured that OpenMoko should > > And it should save the password, so you don't have to type it each time. > > -- > Steven Kurylo > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Another little question about Group sales to steve
> > PS: > I have searched the list ;-) Not well enough ;) The 10-packs are modulo-10, not 10+. You can get 10, 20, 30 not 11, 12, 13 --Steve On Fri, May 16, 2008 at 11:53 AM, Alexander Frøyseth < [EMAIL PROTECTED]> wrote: > Hey folks. > Okey > > I just wondering about one little thing steve. > Is the definition *10 pack* for only 10 persons, or can a 10 pack also be > over 10?? > > Example: Here in Norway we have started a group sale for Norway. And the > chance that we are going to be 10, 20, 30, etc. persons is slim. > So can we buy a *10 pack* when we are 12? > > Or is it only 10, 20, 30, etc groups that can get the extra stuff? > > Alexander Frøyseth > > PS: > I have searched the list ;-) > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stylus Recommendation
Just had a crazy thought while reading this thread Someone (read: not me. I AM a EE :) ) could make a stylus with a usb connector sticking out along the side. Then, the stylus could plug into the usb port and be held tight against the side of the phone. On Sun, May 4, 2008 at 8:33 PM, Jeremiah Flerchinger < [EMAIL PROTECTED]> wrote: > I'd like a Nintendo DS style stylus and holder because they're small, > cheap, & I like how they fit into the casing of the DS. I would try to > use the FreeRunner CAD data > ( http://wiki.openmoko.org/wiki/Neo_FreeRunner_GTA02_Hardware#Case ) to > make my own case mod design if I could find something to convert Pro-E > files. As it stands I refuse to buy Pro-E for a single hobby project. > > On Sat, 2008-05-03 at 09:12 +0200, Nicanor Babula wrote: > > Shawn Rutledge wrote: > > > On Fri, May 2, 2008 at 7:56 AM, Hans L <[EMAIL PROTECTED]> wrote: > > > > > >> I am not an electrical engineer, but I think that the > voltage/current > > >> produced from such a magnet would be negligible. But, even assuming > > >> that it would not be harmful, isn't the case made of plastic? Is > > >> > > > > > > Well you could take apart the phone and try to find a place to stash a > > > small, really strong neodymium magnet. Then use a thin steel stylus > > > (with a soft plastic tip), shaped to fit against whatever surface has > > > the magnet. It could even fit against the side of the phone, if it > > > had a slightly concave shape. Or mod the case to have a shallow > > > groove for the stylus to fit into, then the stylus could just be a > > > thin steel bar, or rounded on one side as suggested. Since the magnet > > > doesn't move, it shouldn't cause any inductive pulses (although it > > > might cause electrons that are trying to move in a straight line to go > > > off in a curve instead. Not sure if that would affect anything...) > > > > > > > > > > > > > Now I am using a motorola A1200E "Motoming" (linux based ;) ) and it has > > a stylus too. I like very much the way the stylus is attached to my > > motorola and I would like to see it on the neo if it doesn't create > > large additional costs. > > > > Check it out: > > http://direct.motorola.com/hellomoto/motomingedge/ > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: .Mac like service
well, if you encrypt the data and store everything as binary, I don't think the version control system would be able to minimize the network traffic. However, I like the concept. If you access the svn server through an ssh tunnel, you'd get the encryption on the link and the reduced traffic. I think you could also user server-side scripts to encrypt and decrypt the stored data on the server. --Steve On Wed, Apr 30, 2008 at 9:29 AM, Flemming Richter Mikkelsen < [EMAIL PROTECTED]> wrote: > > > I think that the best way to implement this is with a version control > system, > so that you may restore your address book from x updates ago, etc. The > version control system should be able to handle binary data (e.g. svn) so > that the information may be encrypted. Using a version control system > would > also minimize the network traffic. > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Charging Neo Freerunner via USB port
Good news, you're likely wrong :) Don't project the current draw when on the charger to when on the battery. It's very normal for the charger portion of a PMIC to be extremely in-efficient. I typically see less than 50% efficiency on chargers. The power system will be optimized for running off the battery, but charger power is usually seen as a free an infinite resource for the phone. It's not worth the cost and area to optimize the power usage from the charger, so it's almost never done. --Steve M On Sat, Apr 19, 2008 at 9:24 AM, "Marco Trevisan (Treviño)" <[EMAIL PROTECTED]> wrote: > > Mhmhm... Does this mean that the freerunner uses about 100mA to stay on > standby? And... Then that in about 12 hours of simple standby its battery > will be out? :o > > I really hope I'm wrong... > > > -- > Treviño's World - Life and Linux > http://www.3v1n0.net/ > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Our new Main page of wiki
Just a thought... Perhaps it would make sense for the wiki pages to fit the horizontal resolution of the Freerunner. I would image that it may be an often visited site by the phones when people are getting started. On Fri, Apr 18, 2008 at 8:51 AM, Brenda Wang <[EMAIL PROTECTED]> wrote: > > Here is the design environment I used. > > Following link is how it looks like . > > > http://picasaweb.google.com.tw/brenda0810/Wiki/photo#5190566071299160210 > > > My resolution is 1024*768 > > Under Windows XP IE 6.0, Mac salaries will look like the attached > > file.(1024*768 windows ) > > Under Linux Firefox 2.0.0.13/Mac Firefox 3.1, the title will turn to > > black. (My setting is use the default color) > > The wiki skin I used is Openmoko (default). > > > > Brenda > > > > Flemming Richter Mikkelsen wrote: > > > > > On 4/18/08, Bastian Muck <[EMAIL PROTECTED]> wrote: > > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA1 > > > > > > > > Too big? Which resolution do you use? 300x200? Ok, with 1920x1200 > > > > many > > > > things can be too small (specially flash videos and fixed sized hps) > > > > but I > > > > think this is also in an usual resolution too small.The solution to > > > > make it > > > > bigger at my browser is not the right way i think. Many people don't > > > > have > > > > good eyes and they should also can read the menu. > > > > > > > > > > > > > > > > > > This is a compromise between too big and including people which use > > > too high resolution. If you have this big resolution, and you don't > > > have any problems on other web pages, you don't have a problem here, > > > right? > > > > > > Adjusting the font size is easy (ctrl-+), except if you use IE (you > > > have to go on View -> Text size -> Largest if you use IE). > > > > > > Some people use special glasses when they use the computer... you > > > cannot expect this wiki to use 24pt text. People like to see more than > > > just a few words at a time. I want to see the whole page without > > > horizontal scrolling and the whole index table without vertical > > > scrolling. I think I am not the only one. > > > > > > I do not have larger resolution that 800x600 here (very little > > > screen), and really hate too large fonts. > > > > > > That is just my opinion. > > > > > > > > > > > > > > > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Car charger to GTA02
a mini-USB to min-USB cable will only have 4 wires. The ID pin is tied to ground at one end of the cable, and left floating at the other. The ID pins at the two ends of the cables to not connect. --Steve On Wed, Apr 2, 2008 at 6:48 AM, Andy Green <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Somebody in the thread at some point said: > > |> Annoyingly enough this will be the hard bit because the fifth ID pin is > |> typically not connected to any wire in the cable. > | > | Good point. Are you aware of any cable that does bring out this pin? > > The three or four that I have hacked about over the years all had only > four wires + shield. > > I guess a mini USB <-> mini USB cable if it existed would at least have > somewhere to connect the ID pin through to, but I never saw one. > > | A workaround would be to construct your own cable from 2 connectors and > | cable. Digikey carries all those connectors. > > Yes, > > http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=H2958-ND > > seems to be a 5-pin plug. > > I pulled apart a moulded one, one of our kit ones I think, they are not > hackable at all. > > - -Andy > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.8 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkfzZF8ACgkQOjLpvpq7dMqIAwCdHIKLmalGzJ57lF+On/Tfw/C+ > ou0AmQEaI+IhCwKm39EARJSbiu3yBhip > =d0dd > -END PGP SIGNATURE- > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
Wow, good to know! Thanks! I have thought for a long time that doing this would be a defense because it would show dated prior art, but the details on that site actually seem more sensible. --Steve On Feb 7, 2008 6:31 PM, Christopher Earl <[EMAIL PROTECTED]> wrote: > Forgot to add this link. This will outline the American procedure for > patenting. > http://www.inventionpatent.net/patent/process.cfm > > >>> "Steven Milburn" <[EMAIL PROTECTED]> 02/07/08 5:35 PM >>> > As a first step, get anything you think is patent worthy documented and > dated. In the US, a common practice is to write up your concept and mail > it > to yourself in a sealed envelope. You don't open the envelope until you > need to and you do it with a lawyer present. The postmark on the envelope > holds up very strongly to prove the date of the material. > > --Steve > > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
As a first step, get anything you think is patent worthy documented and dated. In the US, a common practice is to write up your concept and mail it to yourself in a sealed envelope. You don't open the envelope until you need to and you do it with a lawyer present. The postmark on the envelope holds up very strongly to prove the date of the material. --Steve ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Java games for openMoko
This one-button-at-a-time is not an uncommon to existing phones. Many phone keypads are implemented in such a way that they do not register multiple key presses at the same time. For instance, when playing the "Asphalt Urban GT 3D", a Java game, on my A707, I cannot both accelerate and turn at the same time because it takes two keys. Luckily, the game programmers must have known this and there's a control mode that includes auto-acceleration so that you don't need to press two keys at a time. So, it would be good if the neo could play the games that already exist and only require one key at a time. I'm sure plenty exist for it to be worth while. --Steve On 7/28/07, Ortwin Regel <[EMAIL PROTECTED]> wrote: > > Remember that the Neo doesn't have the buttons for games. The touchscreen > can only do one button at a time, so an external gamepad (USB or Wiimote) > would be necessary. > > Ortwin > > On 7/27/07, John Smith <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > I'm sorry but I'm new to the openMoko system. So my question, is it > > possible to play java games, like for other mobiles, on the openMoko? I > > know, they must be compiled for it. But is it possible to play in the same, > > easy way, some java games? > > > > Thanks, > > John > > > > ___ > > OpenMoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: app idea
Just checked, and my SCH-A707 lets you record something with the microphone and set it as a ring tone. So, at least Samsung thinks the idea has merit! As far as the sharing site thing, I don't think I see why this would be tied to any particular phone hardware or OpenMoko. You could set up a site today that let people share small .mmf and mp3 files. Since the Neo will have web browsing and downloading someday, it could pluck ring tones off any number of sharing sites. H, crazy idea coming to mind.I'm sure my wife (and millions of teens for that matter) would love if the callerID pic that displays when the phone rings could be sync'd with your friend's MySpace or Facebook profile. Personally, I'd hate it. I know she'd love it though. --Steve On 7/24/07, Jeff Andros <[EMAIL PROTECTED]> wrote: yeah, but they seem to be in the minority (my cingular SE phone works properly too) I'm thinking of going a step beyond this: not requiring you to whip out your computer at all. My Sony Ericsson has a program called "Music DJ" that I think I've played with all of twice, but it will let you mix loops to create your own ringtone... what if we go a step farther, and create a composition program with social aspects... allow you to record or create a ringtone on the device itself. The other part that makes this really cool is then uploading this to a sharing site... yes, I know, there's the chance that you record some song off the radio, so we need something to deal with DMCA (it seems a message that says "don't freaking put copyrighted stuff here" is no longer sufficient). Again, I'm having nightmares of people turning recordings of their kids screaming and worse into ringtones... but I think this could be one of the apps that really turns on the mass market On 7/24/07, Steven Milburn <[EMAIL PROTECTED]> wrote: > > Cingular/AT&T doesn't seem to have any problem with letting users make > their own ring tones. On my Samsung SGH-A707, I can select any MP3 file > under 1MB as a ring tone. I have a couple on my phone that I edited with > GarageBand to select a small enough clip and then downloaded to my phone. > > --Steve > > ___ > OpenMoko community mailing list > community@lists.openmoko.org<https://mail.google.com/mail?view=cm&tf=0&[EMAIL PROTECTED]> > http://lists.openmoko.org/mailman/listinfo/community > > -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Unofficial Forum Details...
Kyle, This is probably a crazy idea that if I think long enough about I'd realize won't work. But, instead, I'll just put it out there :) It seems easy enough for the forum and list to connect in one direction, on a user-by-user basis. I assume your forum will have the ability to email registered users with new posts, probably on a per-forum basis. So, developers sticking to the lists could register at the forum, and just have everything emailed to them. However, then it falls apart...unless.. Would it be possible to have the forum itself (or some bot on a server) subscribe to the mailing list? When a message comes into the forum, try to match up the subject line to place the message into the right topic thread. If none exists, place it in a forum called something like "From the List". Further, replies in the "From the List" forum would always be emailed out to the list. This would integrate the forum and lists together pretty well I think. Like I said, probably a crazy idea. --Steve On 7/24/07, Kyle Bassett <[EMAIL PROTECTED]> wrote: Hello Everyone, I have set up the Official Unofficial OpenMoko forum on one of my websites. I will continue to modify the forums as need be. All who would like to utilize the forums are welcome! Temporary Link, awaiting DNS resolution: http://www.makeopensource.com/phpBB3/ Official Link: http://forums.makeopensource.com Please make any recommendations to the layout of the forum to this thread. Anyone that would like to help me administer or moderate the forums, please reply! Thanks! Kyle ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: app idea
Cingular/AT&T doesn't seem to have any problem with letting users make their own ring tones. On my Samsung SGH-A707, I can select any MP3 file under 1MB as a ring tone. I have a couple on my phone that I edited with GarageBand to select a small enough clip and then downloaded to my phone. --Steve ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Charging the NEO1973
I wouldn't bother cutting your cable. Right now, the neo will only switch to 500mA charging when it is successfully enumerated as a high-power device. The only way you'll get it to fast charge from a power-only source, will be to change the software to something like you mentioned. It shouldn't need to take 30 seconds though. Once the neo attempts enumeration (by pulling up on D+ with a 1k resistor), the host should issue a usb reset (single-ended zero) within 500ms. If that doesn't happen, there is no host. On 7/12/07, Brad Midgley <[EMAIL PROTECTED]> wrote: Tim > > According to the wiki, charging the battery is always done through the USB > socket. Does that mean that the NEO is only chargable from a computer I have tried charging from other methods (generic cigarette-lighter to mini usb, solar cell, crank charger) and none of them currently work for fast charging. They may work for the slow charge, but the slow charge is too slow to be useful. The wiki says the neo "could" do a fast charging from these non-host-computer usb ports by trying to pull 500mA when the host does not respond for 30 seconds, but as of about a week ago, the development image does not implement this trick. I might cut open a usb cable and put in the pull-down resistor to see if that works. Brad ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New wishlist item: Side-mounted touch strip sensor
It's been discussed here before (by me ;) ), but I think it's fitting to bring it up in this thread. Mounting a swipe fingerprint sensor on the side would provide the following: * A low-power way to unlock the phone while verifying the user should be unlocking the phone. * Enhanced, or at least more convenient if you believe the anti-fingerprint fud, security for your data * a navigation device that can scroll in two directions as well as include tapping and double-tapping * some gesture recognition for shortcuts (speed dial, application starting, etc) * I'm probably missing some. --Steve ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Iphone 3rd party development allowed...
As of yet, AT&T hasn't disabled bluetooth like you mention. I bought a phone from Cingular/AT&T only a couple months ago. (I chose them because I wanted a GSM phone so I could play with the Neo when it's available). I'm able to transfer music, pics, and other files from my computer to the phone without issue. My brother has a chocolate phone from Verizon, and can't move files from his computer to the phone via usb nor bluetooth. I think what you're saying may be true for Verizon and Sprint. --Steve On 6/5/07, kenneth marken <[EMAIL PROTECTED]> wrote: hell, they have partnered up with AT&T. and isnt mobile operators in the US notorious for locking down what phones can or cant do? i recall reading about bluetooth file transfer being removed and similar so that one had to use their network to transfer data to and from the phone and similar. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SVHMPC] concept phone with only a touchscreen for UI
Well, Bradely's suggestion included making the flip transparent. If it's transparent, the button definitions can still be on the screen, instead of written on the buttons themselves. Now the only thing that is fixed is the shape of the button matrix. Personally, I'd like to see a touchscreen with some type of ability to raise dimples at any point under software control. Kind of like a braille reader on acid. If only such a thing existed. (does it?) --Steve On 6/5/07, Dylan McCall <[EMAIL PROTECTED]> wrote: A problem with the buttons layer is that now we have something very oriented towards one specific situation, so it seems less friendly for random development of stuff, such as full-screen games without actual buttons. Of course this cover would probably be removable, but if it were to happen it would have to be /very/ removable. A great feature to support, as has been discussed here, but not one to demand. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: information efficient text enty using dasher
Many fingerprint sensors that would fit where the button is have a navigation function. They operate much like the touchstick, or a mini touchpad, when not capturing a fingerprint. They are gaining traction in the tablet and ultra-mobile PC market for doing scrolling and simple navigation when a stylus is overkill for a certain quick navigation action. For example, this tablet has one on the top left (as pictured) http://www.tabletpc2.com/Review-FujitsuST5020-Article020605.htm --Steve On 5/30/07, Rory McCann <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Flemming Richter Mikkelsen said the following on 30/05/07 14:21: > Just one more thing > > On my laptop I have this little joystick button in the middle of the > keyboard. If we could get a button like that on the side of the neo > phone, dasher would be great. A little scroll wheel like on mice or on the side of a BlackBerry would be good for Dasher. Scrolling is a common operation, it'd be cool to have it on the OpenMoko. Rory -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXaPKfM8hGU8tATMRAoNXAKDYcXudmdnC2XQfx/CoOrRO9cSOSQCgn1Ur I/EnKOpYTyd51MTpeITDNf0= =8BCe -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: HXD8?
i2c is the interface used to program a camera. The "camera pins" you speak of is the Digital Video Port (DVP). That's the interface the image data goes across. You need both i2c and dvp to use the camera. --Steve On 5/26/07, Erik <[EMAIL PROTECTED]> wrote: > I can't tell you specifics about the end use at this point, but most all > the hardware support is ready. Feel free to look around. > > -Sean Hmmm, the hxd8-core patch says a fair amount: 480x272 screen yes it has gsm same power management unit as neo [pcf50606] s3c2440 cpu ... [built in camera interface] [also usedin ipaq "mobile media companions" rx3115 & rx3715] tsl256x [i2c "light sensor driver" might just be for backlight ctl] http://lists.openmoko.org/pipermail/commitlog/2007-March/001305.html 128mb ram 2mb frame buffer 1gb flash built in, maybe? Hmmm, and lists.openmoko.org/pipermail/commitlog/2007-May/001732.html #defines I2C_DRIVERID_OV7670 as a omnivision 7670 camera, which is an i2c 640x480 camera. But probably not for the hxd8 since that cpu has its own camera pins and wouldn't need an i2c device, right? Looks like it's widescreen and can play back video. -erik ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Battery powered charging/USB hub
btw: That's only works if the port you connect to allows high power devices. Most laptops have only one physical port which will let you enumerate as a high power device, and sometimes even that port only allows it when you're plugged in. So, hopefully the phone will be able to attempt enumeration as a high-power device first, and if nak'd, enumerate as a low-power device. In that case, it would be nice if there was some indication that the battery isn't being charged, or isn't being charged very quickly, whatever the case would be. Also, I haven't checked, but I'm assuming the Neo is a full-speed device. If that's so, there's really no difference to speak of from usb1.1 and usb2.0. both specs have full speed devices, with little changes in 2.0. usb2.0 added high-speed devices. I often hear people say usb2.0 when they mean high-speed, but the two are not equal. Just want to make sure that isn't happening here. --Steve On 5/10/07, Joe Pfeiffer <[EMAIL PROTECTED]> wrote: Frank Coenen writes: >On 5/10/07, Aloril <[EMAIL PROTECTED]> wrote: >> >> Small battery-powered USB charger: >> http://www.ladyada.net/make/mintyboost/ >> I assume above should be able to charge Neo1973? > > >No it won't be able to charge the Neo1973, since it doesn't identify itself >as a USB2.0 host. >Hence, the Neo will only draw 100mA. You need the full 500mA from USB2.0to >charge. That doesn't follow -- USB 1.1 allows a device to identify itself as "high power", and it can then be allowed to draw 5 unit loads (500 mA). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: picture viewer
If you want smooth scrolling, how about this mod to what I said earlier: On the double-tap to center-and-zoom, hold the the second tap. The pic slowly (human speed) zooms and centers to where you're touching. When you've zoomed in enough, lift the finger. This would be similar to the way CTRL-wheel on Adobe pdf's zooms and centers. --Steve ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: picture viewer
Sound pretty good, but I change a couple things from what you describe. For zooming and panning, don't do just the center tap thing. (For one thing, panning doesn't make sense until you're zoomed in). I'd like to be able to do most things without menus or buttons, just learned interaction. To Zoom, double-tap an area, that should cause the picture to zoom and center to where you tapped. Once zoomed in, just drag your finger to pan around. Zoom mode would probably have a few levels, so double-tap again zooms more. In zoom more, there could be either an escape button somewhere, or there could be a miniature display of the full pic, with a box to show the viewable area, and tapping on that display restores the full view. The reason I'm suggesting double tapping is so that you can still have single taps for going to the next and previous picture on the left/top and right/bottom, as well as pulling up a context menu for center taps. That context menu may still include zoom levels, but would have other options also, like sending the pic to someone else, copying, deleting, etc. --Steve On 4/19/07, Ortwin Regel <[EMAIL PROTECTED]> wrote: Dragging motions to the left/right could display the next/last picture. Maybe even better: Only require a single touch at the left or right side of the screen. Makes the screen last longer and is faster. Left and right would be two sides each because the phone could be held upwards and sideways, possibly depending on the individual picture. I like the idea that a single touch (in the middle of the screen, if the rim is used for picture switching) makes on screen controls appear. However, we should think a little more about placement and uses. I think they shouldn't necessarily be at the side of the screen. In fact there should be two prominent ones in the middle of the picture: One for starting a zooming motion, one for dragging the visible area around. You have to start at the buttom but can use the whole screen after that. The button symbols would have to be recognizable equally from both directions. Since they are in the middle of the screen they should probably be transparent to not appear as obtrusive. For rotating the standard corner wheel can be used, though it should be transparent, too. The lower right hand corner (this refers to holding the phone vertically) could then have the button for switching off the controls, the upper left hand corner the escape from slideshow button, both diagonally orientated as to be readable equally from both views. The message of the controls should be: This is a handheld device! It doesn't have to rotate pictures for you. Instead you can rotate the device and enjoy the benefit of using more screen space. The diagonal orientation might make sense for other applications and I'd love to see it used. If you need a mock up to understand this, tell me and I can make one. It will look crappy, though. Ortwin On 4/19/07, Frank Coenen <[EMAIL PROTECTED]> wrote: > Hay, > > Browsing the wiki, I found that the picture viewer was to be a stylus > application. > Viewing photos is something you do together, making it very unpractical to > do with a stylus. > > I think it should be a combination of both stylus and finger. > Managing and looking for a specific dir should be done with a stylus. > Here the approach should be like with the RSS-reader. At the top a list of > photos in your current directory, at the bottom a preview. > > Then you should be able to switch to either slide show or full screen-mode. > Both are the same, with the exception of course that the slide show switches > the photo's automatically (and will rotate them so that the most amount of > screen space is used) > In full screen or slide show mode, if you then press the screen, 5 controls > will appear: > - scroll-wheel - Either for zooming or switching between the photos > - button to switch to either zoom or next-prev-picture mode > - button to rotate the picture 90 dec clockwise > - button to remove the on screen controls again. (so that you will only see > the picture, until you press the screen again) > - a button to go back to stylus mode > > here are two mock ups, note that the left most button will change from zoom > -> switch mode. > http://i172.photobucket.com/albums/w29/baldr_OM/photo_viewer_zoom_mode.png > http://i172.photobucket.com/albums/w29/baldr_OM/photo_viewer_slideshow_mode.png > > Kind regards, > > Frank > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: VoIP call transfer?
Might it be much simpler? On my current cell phone, I can initiate a 3-way call after already talking to somebody for any amount of time. So, when you get home, have a script on the neo start a 3-way call to your home number, which will be answered by your neo's call waiting via wifi, then hang up on the other line (cell). The only thing I wouldn't be sure about is the part about hanging up the first line. I think some systems would cause that to end the entire three way call (my nextel does this). I'm pretty sure that some 3-way systems are done such that when any of the 3 hang up, the remaining 2 are still connected. So, depending on how your carrier's 3-way works, this may be very simple. Here's an entirely different method: Set up a device at home that always will immediately answer a call when the neo is not around, and then have that device initiate a 3-way call through the cell network, which you'll answer with the neo. Ideally, caller-id info can be somehow manipulated so you know where the call really came from. That way, when you get home, you only need a (hopefully) simple program on the neo to smoothly transition from the cell call to the one that's been in progress at home. Perhaps, it doesn't even need to be all that smooth, just ask the party to hang on for a second, and make the switch yourself. --Steve ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
That still requires two hands just to make a phone call. I don't know if it's as bad everywhere else, but American drivers are way too likely to attempt this while driving 80mph in traffic and eating a big mac. The main reason I like the fingerprint sensor concept is that it enables one-handed, no-look speed dialing, while keeping some level of security on the contacts list. I'm seriously contemplating getting a Neo at some point and replacing one of the side buttons with a sensor for this purpose. I think it would be a fun project! --Steve On 3/18/07, Paul Wouters <[EMAIL PROTECTED]> wrote: On Sun, 18 Mar 2007, Steven Milburn wrote: > First, if one concedes that the typical sensor can be easily fooled, I still > think fingerprint sensors tend to add security to most phones. That's > because I think most users cannot be bothered to hide data behind a decent > pass phrase they would have to type on a tiny keyboard. Joe Average is much > more likely to adopt a concept that works something like: Swipe one of your > eight fingers (up, down, left, or right) (thumbs can be dexterally > difficult) and you are authenticates and one of 32 pre-selected actions > happens (call a speed dial, open email, open calendar, etc). It doesnt add more security compared to a "scribbled login pattern". And it doesnt require a fingerprint reader. Paul ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Oh the fingerprint sensor FUD, what fun. First, if one concedes that the typical sensor can be easily fooled, I still think fingerprint sensors tend to add security to most phones. That's because I think most users cannot be bothered to hide data behind a decent pass phrase they would have to type on a tiny keyboard. Joe Average is much more likely to adopt a concept that works something like: Swipe one of your eight fingers (up, down, left, or right) (thumbs can be dexterally difficult) and you are authenticates and one of 32 pre-selected actions happens (call a speed dial, open email, open calendar, etc). A more secure mechanism that no one uses is less secure than an "inferior" one that people will actually use. But, I wouldn't actually concede that a fingerprint sensor is necessary less secure than a typical password. These days some can be very difficult to spoof. Almost no swipe sensor targeted to cell phones is an optical sensor these days. The common, cheap ones use capacitive sensors. The better ones use active RF sensing, with sophisticated anti-spoof measures built-in. Some of the more advanced sensors even have the ability to securely store keys right on them, and some even have the ability to encrypt/decrypt data for you once you authenticate, with the keys never leaving the sensor. I say all this just to try to clear up some of the FUD. But, I realize full well that suggesting fingerprint sensors is in no way an answer to the security question on the Neo. I don't even think it makes sense to push for a fingerprint sensor to be included in the hardware rev, because there are better things to concentrate on at this point (wifi). --Steve On 3/18/07, Ian Stirling <[EMAIL PROTECTED]> wrote: Henryk Plötz wrote: > Moin, > > Am Sun, 18 Mar 2007 18:40:26 +0100 schrieb [EMAIL PROTECTED]: >> I would appreciate a fingerprint sensor - there are a lot of Asian >> mobile phones / smart phones >> with a fingerprint sensor... > > Yeah, but a fingerprint sensor adds only convenience and no security > at all. starbug regularly demonstrates circumventing any fingerprint It can add some security, especially against most opponents that are not going to bother to try to fake the print. For example, four fingers, scanned either upwards or downwards gives you 8 'keys'. If you add a 90 degree rotated finger, that gives you 4*4 = 16 keys. And as the sensors are typically designed as a 256*4 or so camera, you can basically do an optical mouse with them, in reverse, using the finger as a 'surface', to add gestures in the middle of the prints. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OT] Re: data encryption + Biometric security
Malicious people will cut off your finger. Don't laugh, it has happened before. There are proven cases, e.g. where a carjacker cut off the finger of his victim in order to be able to steal the car. Newer fingerprint reader technologies actually account for this pretty well. A detached finger is seen as a spoof attempt, if it even images properly at all. Your information on these sensors, like most people, is outdated. And I don't think that's really an accident. But, let me humor you for a moment. If I'm willing to cut off your finger to get into your mobile device, why wouldn't I be willing to put a gun to your head and/or torture you until you give me your password? 1) full hardware docs (may be under NDA, but allowing GPL software development) 2) small enough for a mobile device 3) cheap enough 4) not easy to fool The sensor Mark's talking about definitely fulfills the last three. As for #1, that's where the political work needs to be done. It should be possible to make this happen though. Most, if not all, fingerprint sensor manufacturers are in the business of selling hardware. The software is basically given away, although the algorithms are guarded. They need to control the software because the quality of the sensor depends on the software. I image all that's needed is an easy way for users to tell that a sensor is being used with the company's software or something else. That way, when used with something else, the reputation of the quality of the sensor is not on the line because of bad software. Eventually, the open software may get good enough that the companies would "bless" a certain build. On 2/3/07, Ian Stirling <[EMAIL PROTECTED]> wrote: There are not-bad options - with something like a 4*256 pixel imager. Cheap, pretty small, docs - as it's just a camera, easy to fool... Well, it's a fingerprint sensor. If people are being concerned about faking fingerprint sensors, then this simplistic approach is definitely not a good idea as optical imagers are the easiest to fake out. There are interesting possibilities to add security to fingerprint sensors. For example, which finger? If three fingers of one hand have to be scanned in a particular order, or it requires a password afterwards. Or use it as a little optical mouse backwards, and have a 'signature'. It can even be used as a substitute for a thumbstick in the normal UI. All the above is currently being used. There are swipe-based fingerprint sensors on some tablet PCs that have navigation capability. They are used as scroll wheels and/or as backup when the stylus is lost or not necessary for a simple task. But, as of yet using them for full navigation is not working so great. The main problem I see with all the ones I've tries is that they actually try to mimic touch pads, instead of touch sticks. So, to move across a screen, you have to keep swiping. That's an easy fix though if the open-source community were able to work on things. In fact, I think most of the standard gripes about fingerprint sensors could be fixed if the community could play with the sensors, instead of relying on the algorithms of the few corporate players in the market. --Steve Disclaimer: I USED to work for a fingerprint sensor company. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: 2-3 parallel solution to choose by the user? Re: Any alternative ideas to fullscreen popup-messages?
I tend to be of the mentality that the phone is for my convenience, not
others. Therefore, I like the ideas being suggested that incoming
calls/text messages/emails/etc are indicated by a simple, polite icon on a
status bar somewhere flashing for my attention.
If the application I'm running is screen or input-centric, the icon works
great, because I'm looking at the screen. Also, in these applications, the
current ringer setting would also apply as a way to alert me to the call.
If the application is sound-based, like playing an audio file, I would think
the a nice pleasant and quick tone, like caller-ID uses, would suffice to
alert me. If I take no action, perhaps I don't have the head phones on
right now, and the phone should use the ringer/vibrator after a couple
rings.
I really think in most circumstances, the ringer/vibrator on the phone is
enough to get one's attention, and all that is needed is a consistent place
to click to accept or reject the call.
(hmm, the Neo does have vibrate, right?)
--Steve
On 1/31/07, Michael 'Mickey' Lauer <[EMAIL PROTECTED]> wrote:
Heya,
> I think many users could live with popups,
> but I would like to choose a solution that
> would not nag me with full or havesize popups
Do you have a viable alternative (except full undo/redo capabilities,
which would be desirable, but takes a whole lot of memory and/or
disk)?
>> Let's distinguish two types of popup-dialogs:
>>
>> a) informative (i.e. battery low, incoming sms, sms sent)
>> b) confirmative ("Mickey calling. Answer / Ignore / Reject?", "Do you
>> want to remove all contacts?")
> b) I hope incomming call will not interupt me to do what I'm doing
>now
D'oh. That surprises me a bit... after all, the Neo is a phone, so I
would think incoming phone calls should always popup [in default
profile]. What do the others think?
>> Right now, we're leaning towards (ab)using the bottom status bar (in
>> openmoko-language called 'footer') for informative dialogs and using
>> half screen (480x320) popup dialogs for confirmative.
> - I guess a third 480x210 is to small?
Probably, yes.
> - could it be transparent?
Not on v1 hardware. There is no way the composite render extension
will work with an acceptable speed on a s3c2410.
> - will it passiv so that I can go on typing my email/chat
> and my external keyboard return will not activate the
> default of the pop up?
I don't think we want "Do you really want to delete all contacts" to
be a non-disturbing passive dialog.
>> What do you think?
> I think for several application I would like to have
> *no* popup just a screen inverting flashing like with GNU
> screen and maybe a 1-3 pixel red or inverted frame around
> the whole screen - mabey with fast inverting flashing
> mayby with vibra or sound alarm... but a chance to
> to continous with the full screen.
Let's talk more concrete. Can we come up with some examples which are
asynchronous notifications requiring a confirmation (otherwise they'd
just appear and disappear on the statusbar)? Do you really want e.g.
the "incoming phone" confirmation dialog behave like that?
[more notification strategies]
> When I work with my laptop and the phone rings,
> I can finshed what I'm doing and pickup the phone
> then - the same freedom would I like when computing
> and phone will be together in a smartphone.
> Could you understand my point?
I understand your point, I just think that this kind of thinking is
not what the majority of smartphone users wants or is it? Guys?
> So in oposite to comercial products we have to chance
> offer 2-4 different design solutions how to work with
> the device.
Absolutely -- that's freedom. Giving hard- and software to actually
try new paradigmes in the real world might exactly be the revolution we're
after :)
--
- Michael Lauer <[EMAIL PROTECTED]>
http://openmoko.org/
Software for the worlds' first truly open Free Software mobile phone
___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community
___
OpenMoko community mailing list
community@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/community
Re: idea for Neo 2nd generation: Accelerometer
- Forwarded message -- From: Gabriel Ambuehl <[EMAIL PROTECTED]> To: community@lists.openmoko.org Date: Fri, 26 Jan 2007 19:13:49 +0100 Subject: Re: idea for Neo 2nd generation: Accelerometer On Friday 26 January 2007 18:41:50 Tim Newsom wrote: > > yes, accelerometers measure acceleration. The first derivative of > > acceleration is velocity. > Ok Steve. I grant you that the first derivative of acceleration is > velocity... I don't think so. The first derivative of VELOCITY is acceleration (i.e. integrate acceleration to get velocity as acceleration is the rate of change of velocity) if my high school physics doesn't totally fail me right now. This also means that if acceleration is zero, velocity simply is constant. And in order to have velocity >0 you must have encountered some acceleration at some point. Wow, I can't believe I got that backwards, thanks for the correction. Kind of embarrassing considering I actually work on this stuff. However, it doesn't invalidate that you don't need any more information than the accelerometer and a starting point in order to track velocity and position. I'm going to go work on removing the foot I shoved so far into my mouth earlier. --Steve ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Developers phone also fit for early adopters?
-- Forwarded message -- From: Sean Moss-Pultz <[EMAIL PROTECTED]> To: Marcus Bauer <[EMAIL PROTECTED]>, Michael 'Mickey' Lauer < [EMAIL PROTECTED]> Date: Sat, 27 Jan 2007 01:37:39 +0800 Subject: Re: Developers phone also fit for early adopters? On 1/26/07 9:40 AM, "Marcus Bauer" <[EMAIL PROTECTED]> wrote: The fact that I didn't answer to that mail doesn't mean I didn't read it. Should I now say you obviously didn't follow your own annoucements and didn't read the topic you set on IRC because you said the phone would come out in January? Listen, there's nobody on this list that wishes we'd had this phone out in January more than I. But delays happen. You can't seriously be calling us liars now are you? -Sean Sean: I think you missed the sarcastic hyperbole that Marcus was attempting to use. He was basically saying that calling you liars would be about as wrong as assuming since he didn't reply, he must not have read a post. It's a weak comparison, but no, he's not seriously calling you all liars. I could be dead wrong here of course, but that's how I read it. Marcus: Either way, it was a pretty poor direction to take things in and does nothing to help foster the spirit of cooperation that will be needed to make this program a success. --Steve ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: idea for Neo 2nd generation: Accelerometer
We also need to take into account that accelerometers measure acceleration. If you accelerating or decelerating it will be able to tell you the magnitude of the force and you can time the duration to find the distance traveled. However, suppose that you are moving at a constant velocity, the accelerometer will measure 0 (zero) acceleration. Most true vehicle dead reckoning systems also include a sensor for the vehicle speed, which in combination with gps can provide you with something the accelerometer can't. The ability to know how far you have traveled at a constant or accelerating speed. Anyway, since attaching a sensor to the car may not be possible its a moot point. Just thought I would add a few more cents in. As a side note... In the US and probably other countries there is a standard for the interface to the car computer. From that interface you can get the vehicle speed and diagnostic information about how the engine is running. It might be interesting to have some kind of bluetooth car interface to obtain that information and display it for you while you are in your car. Anyone ever heard of anything like that? --Tim yes, accelerometers measure acceleration. The first derivative of acceleration is velocity. Granted errors in the accelerometer compound when deriving velocity, but you've usually got GPS information to calibrate against (As Jeff was saying). A typical dead reckoning system always knows your current velocity, and when GPS goes away, it can apply changes to the velocity by knowing only your current acceleration. The errors associated with this would typically be small enough to not matter during the length of a tunnel or building related GPS blackout. So, an accelerometer (actually, three) is all that is needed for a complete navigation with dead reckoning. An accelerometer could have other nifty applications. Here's a few: Tape measure: walk the unit from one corner of a room to another and see both the x and y (even z) distances. Would be very useful for construction and event production professionals Games: Use the entire device as a steering wheel in a car game, or yoke in a flying game Pedometer: if accurate enough, could count actual steps walked and convert that to calories burned. Or could count paces when following a pirate's treasure map. Subway system: Could tell you where you are, and wake you up or alert you when riding the subway. (Since no one can usually understand the announcements) --Steve ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
