Re: OpenMoko at SCALE
Joe Bushong wrote: Any chance of the OpenMoko team participating in the Southern California Linux Expo (SCALE) http://www.socallinuxexpo.org/ It is February 10-11 in Los Angeles and would be a great opportunity to show off some open-source hardware to like minded Linux geeks. I am planning on being there as part of the Haiku OS booth and it would be interesting to see some of the people from this mailing list as well. The NSLU2-Linux project has a booth (see last year's booth at http://www.nslu2-linux.org/gallery/SCALE4X ), where we demo the Linksys NSLU2 running the SlugOS open-source firmware based on OpenEmbedded (which makes SlugOS and OpenMoko sister Linux distributions). We'd be happy to make some room for a demo OpenMoko device. Send Tom an email if you're interested. -- Rod Whitby -- NSLU2-Linux Project Lead ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: (re)charging control
Dnia poniedziałek, 27 listopada 2006 18:30, Robert Michel napisał: On Mon, 27 Nov 2006, Marcin Juszkiewicz wrote: 1. user is at home (where is charger) There is no need for a propritary charger ;) The charger will be a normal powerd USB port, so you can also - charge it at work, - with your laptop - There are also cheap 12V car adapter to power up there... - and I would like to see a small inexpensive adapter to AA / 9V battery for contingency - just pick some batterys from another device or by normal batteries (gettable at every corner) But I *do not* want to keep usb cable in my pocket. FIC phone will get Mini-B connector for charging/connecting. Do you know how many types of Mini-B connector are in use? I have atleast 3 such cables at home and I know devices with Mini-B which I cannot connect due to lack of cable. If yes - two battery blocks with a software controled anlalog switch instead of one would be the better design - the user could full discharge one battery before he charge it again. It bump price and weight so please do not go this way. 2. battery is 'in 10-14h will be empty' So when I have a Neo1973 my first crontab would be a small script, that it will check every 15 minutes if the battery has become lower then 7% - when there is no phonecall or activity - give a warning and switch of. That kind of stuff will get your battery discharged faster. You should rather follow acpid/cpufreqd configs. Anouther idea would be a semi-online status when you are sleeping, or travelling your device would be online only from time to time, e.g. 30 minutes intervall - asking your sever if someone tried to call you - or did send you a SMS and then swich off again. And you will miss all calls during being 'semi online' - great stuff for phone... sorry that I was unavailable but my phone was in semi-online mode to preserve battery. -- JID: hrw-jabber.org OpenEmbedded developer/consultant I saw what you did and I know who you are. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: (re)charging control
Salve Marcin! On Tue, 28 Nov 2006, Marcin Juszkiewicz wrote: Dnia poniedzia??ek, 27 listopada 2006 18:30, Robert Michel napisa??: On Mon, 27 Nov 2006, Marcin Juszkiewicz wrote: 1. user is at home (where is charger) Sorry, I was so happy that this phone will do not need a propritary charger - that I forget to write you that the idea of a charching reminder/alert when the user came at home is a very good one. In general such a todo alert when the user came to a localisation (home/work/shop/bank/post/gasoilstation...) would be great - buy 2l milk - get 50 Euro from the cach mashine - buy 10 new stamps - check air and oil So it would not be a stupid alert everytime the user came to on localisation, the function would make a database request and when the value is over or ander a given limit it will makes an alert. The limit could also be a value from a database or a funcition, e.g. befor a weekend the milk reminder (just simple supied example) would have the value of 4l The same with your accu recharger, when you are planing to travel, or leave your home for more than a day your function should remember to charge the phone to 100% There is no need for a propritary charger ;) The charger will be a normal powerd USB port, so you can also - charge it at work, - with your laptop - There are also cheap 12V car adapter to power up there... - and I would like to see a small inexpensive adapter to AA / 9V battery for contingency - just pick some batterys from another device or by normal batteries (gettable at every corner) But I *do not* want to keep usb cable in my pocket. There are small 3 cm long adapters - no need for a cable. And better to have such an adapter or cabel with you than a second propritary charger ; And this cable is dual use - also for data connections ;) I also not so happy about the Mini-B female jack - I would prefer a normal USB female jack that you could pluck in normal USBmenory sticks/adapters in. Buy having a normal male USB jack on the phone you could plug it directly into USB female jackes of laptops, some autoradios... So a male and femal connector would be nice - but uses also quite much space of the phone. But how ever, would you be more happy with one propritary charger? I don't think so - I think it is very cool that the device could be charged via USB. But I *do not* want to keep usb cable in my pocket. What alternative would you propose? A fix solderd male USB jack on the device? Do you know how many types of Mini-B connector are in use? I have atleast 3 such cables at home and I know devices with Mini-B which I cannot connect due to lack of cable. You are right the high number of different USB cables are ugly and unsmart. But that the neo will be chargable via USB, I think, is still much better than a propritary charger ;) If yes - two battery blocks with a software controled anlalog switch instead of one would be the better design - the user could full discharge one battery before he charge it again. It bump price and weight so please do not go this way. It was just an idea how to encrease the reliability. BTW I would like to see standard battery cells - maybe not AA/AAA but someone that could be bought easily. 2. battery is 'in 10-14h will be empty' So when I have a Neo1973 my first crontab would be a small script, that it will check every 15 minutes if the battery has become lower then 7% - when there is no phonecall or activity - give a warning and switch of. That kind of stuff will get your battery discharged faster. You should rather follow acpid/cpufreqd configs. Ok good hint. :) Anouther idea would be a semi-online status when you are sleeping, or travelling your device would be online only from time to time, e.g. 30 minutes intervall - asking your sever if someone tried to call you - or did send you a SMS and then swich off again. And you will miss all calls during being 'semi online' - great stuff for phone... sorry that I was unavailable but my phone was in semi-online mode to preserve battery. Yes - when you are travelling on a weekend or on a holyday - even when I'm sleeping it doesn't hurt wenn somebody needs 30 minutes to reach me - it is better to have this delay than reachable only on the first of 3 days. You don't need to use it, but this idea can't you realise with much other phones ;) Greetings rob ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Can The Proprietary GPS Daemon Be Removed?
Hi, In userspace, there only one single component that is not going to be under a Free Software License: It's our GPS daemon. The reason for this is, that the specific high-sensitivity assisted GPS that we wanted is only available in something like a soft modem GPS, e.g. one that does most of the GPS signal processing in software. - http://gnumonks.org/~laforge/weblog/2006/11/08/ Can this proprietary, unethical, unsustainable GPS daemon be removed simply and cleanly while not effect any other functionality that's not GPS-dependent? Are there any plans to write a Free GPS daemon in the future, once the phone is successful and the next version is being developed? :-) And can someone confirm the GSM part is Free? :-) -- Regards, Dave ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Can The Proprietary GPS Daemon Be Removed?
On 28/11/06, Dave Crossland [EMAIL PROTECTED] wrote: And can someone confirm the GSM part is Free? :-) Reason I ask is: There are some minor, self-contained proprietary bits on the back end side in userspace. - http://gnumonks.org/~laforge/weblog/2006/11/08/ which appears to contradict In userspace, there only one single component that is not going to be under a Free Software License - http://gnumonks.org/~laforge/weblog/2006/11/08/ -- Regards, Dave ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Voice recognition
On 11/27/06 8:01 PM, Alessandro Iurlano [EMAIL PROTECTED] wrote: I would like to know if there will be some kind of voice control/recognition on the phone. If so, I would like also to know which sw will be used to implement it as I would like to develop some kind of interface based on speech on the phone. Right now no. But it's totally open source...so if you have something in mind we'd love to support your efforts. -Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
RE: [Spam?] Re: google earth - [was: Re: Another simple GPS+GPRS idea]
I have a bit of experience in GIS data and applications. Okay, a lot. Sean is absolutely right about the rarity and high price of street maps, not to mention the legal rights problems which can drag in Queens and Kings. The first question to answer is: what is the necessary accuracy? If you're not routing ambulances then there may be adequate data available from public sources. Availability varies tremendously by country, even by internal divisions, but streets are always changing, hence more difficult to obtain. If street level geocoding is needed, one approach would be to take advantage of Google or Yahoos geocoding APIs. Would work for a limited (but large) number of hits/day, and for a non-commercial application. For basic context like major roads, landmarks, postal code or political boundaries, data may well be available for free or the cost of bashing them into a useful shape. These data also have the advantage of smaller file sizes. Hope this helps. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Moss-Pultz Sent: Tuesday, November 28, 2006 10:25 AM To: Marcus Bauer; community@lists.openmoko.org Subject: [Spam?] Re: google earth - [was: Re: Another simple GPS+GPRS idea] Importance: Low On 11/27/06 8:16 PM, Marcus Bauer [EMAIL PROTECTED] wrote: You may ask Sean about availability of maps for the Neo1973 (a quick search in the ML-archives gives no hits). Mapping data is actually really difficult. There are only two providers worldwide: * Navitec * TeleAtlas And they are really expensive. We have some commercial software lined up that we could sell, but I'm not too excited at anything at this point. Hopefully we can come up with something free together. -Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information of Motricity. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
X and Matchbox
Hi, I have several questions regarding the graphics support. As far as I know the Neo uses X and Matchbox as Window Manager. Do you know if the video driver that X uses has been specifically developed/modified for this platform? X can be adapted for embedded devices (like in the Zaurus) for being as light as possible. In the Neo how much memory and footprint does X needs? Does OpenMoko support Frame Buffer? Using the FB could be interesting because some graphic operations could be improved. Have you ever tested it with other Window Managers? I know Matchbox was specifically designed for this kinf of devices, but WindowMaker and Blackbox, for example, are very light and fast too (and they support virtual desktops that could be nice to have). Thanks! Pedro Aguilar ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Standard AA accumulators / batteries
Hi, I think it's a good idea to use standard AA batteries or accumulators. They are easy to find anywhere, and they're cheap. There has been a steady increase of capacity over time of the AA Ni-MH accumulators, with capacities that I see in stores today of 2700 mAh (1.2V), and it's likely that the capacity of the standard accumulators will continue to increase over time. Perhaps everybody already has at home a few AA accumulators and a few AA chargers. I would be curios if somebody on this list could do a comparison WRT energy capacity and energy density between a pair of 1.2V, 2700mAh AA accumulators and the 1200 mAh battery that is mentioned in Neo's spec. Good luck, and I look forward to develop applications for the open phone. Mihai Preda Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: [Spam?] Re: google earth - [was: Re: Another simple GPS+GPRSidea]
On 11/28/06, Sam Kome [EMAIL PROTECTED] wrote: I _love_ the idea of openstreetmap, but truly doubt that it will retain enough dedicated participants over time. Initial capture is not enough; eternal vigilance is needed to recapture the data everytime a bulldozer appears or a planning committee renumbers the addresses. I disagree, I'm not a GIS-ologist, but my assumptions is that OpenStreetmap, or a similar project, will continue to grow slowly until: a) GPS devices become ubiquitous, as does the technology to streamline and facilitate the acquisition and syncronisation of 'tagging' info. b) Some corporate or governmental agency acquires the rights to place such streetmap data into the public domain. Likely a result of widespread GPS adoption (a). You are right in that if you look at who is creating these uploads, it is mostly a small subset of devotees.. however for all the towns and cities I've lived in, the actual street layouts and names don't change terribly often. One thing the Neo1973 should be able to do easily, which would differentiate it somewhat, is that it could time its GPS acquisitions to fill in the missing datapoints, by comparing existing datapoints - if a road takes a sharp bend, the extent of which is not picked up by the first pass: [EMAIL PROTECTED] | @ | Then the Neo could compare its own vectors, and the timestamps for the first pass.. and flesh out the missing corner, add a few more passes and you've boosted your accuracy. Dedicated participants, as you say, are only required at the early-adoption stage because they are the ones who end up creating the mechanisms which the masses end up using? Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: X and Matchbox
Pedro Aguilar wrote: I have several questions regarding the graphics support. As far as I know the Neo uses X and Matchbox as Window Manager. Correct. Do you know if the video driver that X uses has been specifically developed/modified for this platform? It is the standard xorg-x11-kdrive server. X can be adapted for embedded devices (like in the Zaurus) for being as light as possible. In the Neo how much memory and footprint does X needs? I didn't have a chance to write down numbers yet. Will do when I'm working on the hardware again. Does OpenMoko support Frame Buffer? Using the FB could be interesting because some graphic operations could be improved. We don't recommend direct frame buffer access, but if you absolutely need to do it to squeeze out the last bits of performance, then you're free to halt X and talk to /dev/fb. We rather want to support SDL which plays nicely with X. Have you ever tested it with other Window Managers? I know Matchbox was specifically designed for this kinf of devices, but WindowMaker and Blackbox, for example, are very light and fast too (and they support virtual desktops that could be nice to have). We don't have special requirements to a window manager, since most of the UI is drawn by Gtk and there are almost no window decorations -- this is the primary use case for MatchBox. Virtual Desktops is -- as the name says -- a desktop paradigm. It was designed for when you have a lot of application windows concurrently on a screen which all have dedicated geometry and you want to save state when switching between these desktops. I don't think this will be of much use on a phone since we run applications one-window-full-screen on OpenMoko. -- Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Security/voicemail idea
Hello everyone, while reading various posts, I remembered a presentation I attended once on a different topic (security management) that included an interesting idea for (mobile phone incoming calls) access control. It seems related to some ideas already raised on this list with respect to automatic answering. You will find the reference here: http://www.laas.fr/~esorics/notices/Rannenberg2000.html I dunno if the full paper is available somewhere. However, I remember the author saying that his specific audience (primarily in the health care sector: praticians, doctors, etc.) became addicted to his addons pretty fast. Rodolphe PS: After looking for a while, I found a ref to the full paper here: http://www.wiiw.de/publikationen/MultilateralSecurityAconcepta433.pdf PPS: The author is apparently working now for http://www.whatismobile.de/; (!). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: [Spam?] Re: google earth - [was: Re: Another simple GPS+GPRSidea]
On 11/28/06, Richard Franks [EMAIL PROTECTED] wrote: however for all the towns and cities I've lived in, the actual street layouts and names don't change terribly often. Let me qualify this rather anecdotal statement.. I don't think street-layout/renumberings change often enough to be show-stopper problem for a project like OpenStreetmap. If you work a lot with streetmap data, then you probably deal with renumbering/layout changes on a daily basis. But what percentage of roads require such changes per year? What percentage of the total streetmap mileage is affected? Does this occur more frequently in urban, suburban, or rural areas? I think you'd need to take account of at least these variables to determine the extent of the problem, and the ease of the fix. I'm also thinking in terms of highway maintainance -- if one section is under maintainance, and traffic from both directions are forced to share one side of the highway.. then temporary traffic information could be mined quite easily if the highway is wide enough to draw conclusions from the offset in expected GPS vectors. Likewise for accidents, or temporarily blocked roads. All it requires is a few more programmable GPS devices on the roads who share data, and you have the basis for an automonous dynamic nagivation system, which has the potential to report back issues rather quickly. Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: X and Matchbox
Related to this, was my question about themes. I will have to check out the abilities of the gtk theme engine in regards to this, but I have an interest in porting the LCARS theme from the 770 or other themes to the phone. It would seem to me (and maybe I don't understand as well as I thought I did) that the ability to theme the interface could help usability studies / testing of new phone interface designs. The ability to design and quickly switch between different designs would be of importance in that situation. Note, when I talk about themes I am not talking about just changing the graphics but also the locations of various rendered buttons and interface elements in order to find optimal locations. I am not sure how far you could go with it, but if its easy to do then you know people will jump on it. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re[2]: X and Matchbox
Tim Newsom wrote: Note, when I talk about themes I am not talking about just changing the graphics but also the locations of various rendered buttons and interface elements in order to find optimal locations. The only GUI toolkit that makes this possible is the Enlightenment EFL. Unfortunately it was not mature enough at the point where the OpenMoko team had to choose their base toolkit. Regards, :M: -- Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: (re)charging control
On 11/28/06, Sean Moss-Pultz [EMAIL PROTECTED] wrote: On 11/28/06 2:24 AM, Tomasz Zielinski [EMAIL PROTECTED] wrote: Questions to hardware developers: 1. How long does the battery live with only GSM unit active? 2. How long with GSM and GPS? 3. How long with GSM, GPS and Bluetooth? We really don't have these answers at this point. I will keep you all posted. 4. Is the user-mode software allowed to turn on and off various modules? In example: crontab task turns the GPS on, read coordinates, process them, turns GPS off and sleep for 15 minutes. This is an open device...even down to the kernel. Whether we allow this or not, if somebody wants to do it, it can happen ;-) -Sean Um, the only thing I see as a problem, since you said in a previous email ( or later, I'm not sure, this is the order I read them) that all the hardware requires an non-disclosure, either you're going to need to provide access to the power up/sleep commands thru the drivers, or reverse engineering this is going to suck, assuming there's even a software sleep command(I'd assume so, but normally that begets bad things) even a nice constant for the commands, and a passthrough character driver would be really nice. I'm not asking you to go farther than your agreement, but if you could map the system commands for the major components into the driver, that would be a wonderful help Thank you so much, Sean, for making this all possible, it's really a wonderful thing --Jeff ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: voice recgonition
On 11/28/06, Joel Newkirk [EMAIL PROTECTED] wrote: Robert Michel wrote: Salve Richard! I like your ideas here, ;) it definitely looks feasible to support a small subset of voice-commands.. Yes/No/Again/Next could be standardised and available to all applications. AFAIK will a small number of different voice commands have a good regognize rate. IBM released a modified multimodal Opera web browser for the older-style Zaurus (Embedix linux) that supports voice interaction tags - Websphere Everyplace Multimodal Environment. I've played around with it, and it works pretty well. By using XML (XHTML plus VoiceXML, actually) and defining limited-domain voice tags within a document it can distinguish spoken numbers, names, pizza toppings, etc without training. The engine should be able to handle a screenful of 9-16 icons by name plus basic menus, for example. As long as each item consists of a distinct series of phonemes it's smooth. (it doesn't need to hear the difference between 'whiter' and 'writer' - it's not speech-to-text) I for one find 'voice tags' on my cells to have been irritating, but have always wanted to be able to just recite a number and store or dial, or fire up the calculator and run some calculations, without pressing buttons or navigating menus. Between that and FLite (Festival Lite speech synthesis engine, available for the Zaurus and various ARM-Linux distros) you have the underpinnings of some very interesting possibilities. j Hey! and OpenMoKo is supposed to be build compatible with Zaurus apps, right? so we're half way there --Jeff ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
