Re: Bluetooth questions from a bluetooth guy [Was: collaborating on bluetooth audio]
Fabien An interesting development has made it clear that your flowcontrol work and sco audio server are relevant for neo: http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=583 any sort of voice application like voip will have to use sco over hci because of limitations in the codec connected to the bluetooth adapter. It's a good thing neo has an adapter (csr) that is proven for this kind of stuff. Brad ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: information efficient text enty using dasher
[EMAIL PROTECTED] wrote: > Dasher is only really information efficient considering the input only. > The output stream needs to be quite dense. I was commenting on "finger splash". I agree that Dasher seems extremely stressful, more like a fast-paced video game. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ 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: information efficient text enty using dasher
Dasher is only really information efficient considering the input only. The output stream needs to be quite dense. This pretty much means that you have to stare at the display all the time when inputting text. Sure - in theory, dasher may approach arithmetic coding in terms of information input. But unless you can do the coding in your head, you've got to stare at the screen, making it less useful for environments where you've got vibration, sunlight, walking down the street, or less likely for a phone, if you're blind. (Hmm. /me ponders dasher with audio prompting) T9 or even abc def ... you can use blind. Even qwerty with real hardware keys. (I think on-screen keyb would be optimistic :) ) To me, it looks like Dasher has a some drawbacks: one, it seems to be CPU intensive - there's a lot of animation going on during text entry. Not a problem for PCs, but it might not be optimal on a low power device. two, its storage intensive. You have to have a dictionary of some sort available for it to do its prediction. Or, several dictionaries, each for a different type of text entry (like english and japanese, or english and C++ programming). three, it takes up a lot of screen space. If you are just doing pure text entry without needing to look at something else, that's ok. But I'd rather it didn't take up the whole screen so that I can't see an IM that I'm replying to, or several lines of the website form I'm filling out. That's not to say I'm against Dasher. But I'd like to see a lot of flexibility available in openmoko text entry so that I can change to dasher, or some other text entry method when needed, or just to try things out. I hope someone will implement it for openmoko, together with several other alternatives for doing text entry. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: information efficient text enty using dasher
> Jonathon Suggs wrote: >> My favorite input method is still the finger splash concept (needs some >> tweaking to the concept though) >> http://www.micropp.se/openmoko/ > > I like that one. One issue would be the font size, though - the > secondary letters are quite hard to read on the Neo, and the > multi-letter functions are basically unreadable (while > "unsplashed"). Dasher is only really information efficient considering the input only. The output stream needs to be quite dense. This pretty much means that you have to stare at the display all the time when inputting text. Sure - in theory, dasher may approach arithmetic coding in terms of information input. But unless you can do the coding in your head, you've got to stare at the screen, making it less useful for environments where you've got vibration, sunlight, walking down the street, or less likely for a phone, if you're blind. (Hmm. /me ponders dasher with audio prompting) T9 or even abc def ... you can use blind. Even qwerty with real hardware keys. (I think on-screen keyb would be optimistic :) ) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New CPU
Yes. Some CPU is few clock cycles on calculations, others are optimized for I/O. The important thing is how many clock cycles it will use in average on an instruction. For video and audio, lets hope it is fast with mathematics. For power, maybe we can change the freq. with software (something simmular to cpyspeedy) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: information efficient text enty using dasher
Jonathon Suggs wrote: > My favorite input method is still the finger splash concept (needs some > tweaking to the concept though) > http://www.micropp.se/openmoko/ I like that one. One issue would be the font size, though - the secondary letters are quite hard to read on the Neo, and the multi-letter functions are basically unreadable (while "unsplashed"). - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: tomtom on the Neo1973
Yes, but if I am relying on my device to be able to get from point A to point B then I would MUCH rather have it be able to give me an accurate map and directions. Its almost a chicken and egg problem. TomTom only sells/ports to high volume platforms. Platforms need TomTom (not specifically, just in general) to be mass marketable. I fully plan on supporting OpenStreetMap (although the US coverage is terrible), but it is NOT ready for use outside of enthusiasts and certainly NOT ready to be a mass marketable option. Ian Darwin wrote: And besides, wouldn't you rather have an open source program drawing your maps? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: information efficient text enty using dasher
I did the same thing. I had played with it in the past using the browser applet and it really didn't do it much justice. I put it on my pda and (after some training) and you were inputting common words, then it wasn't that bad, but still not a super intuitive method for input, but may be a good option since we don't have a hw keyboard. My favorite input method is still the finger splash concept (needs some tweaking to the concept though) http://www.micropp.se/openmoko/ Thomas Gstädtner wrote: Btw: I tried dasher for some minutes and its a bit hard at the beginning. After 5-10 mins of training it works very well! ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: tomtom on the Neo1973
Ian Darwin wrote: I think you're right; after the first 250,000 or so Neo 1973 phones have been sold, they *may* look again. There are currently under 350 signups, so I wouldn't hold my breath if I were you. If you just want to use a $350 Neo as a $200 GPS, you might as well spend the time on a mashup of RoadMap and OpenStreetMap. In re-reading my post I see it could be taken as critical of the project; no, I am a big fan of the project. I just don't think people should expect instant recognition from big vendors that are used to dealing in huge (comparatively) sales volumes. According to tomtom.com, as of this very month they have sold TEN MILLION GPS units. It costs most "big" software companies many, many thousands of dollars to do what we think of as a "port" because of their overhead, and they won't generally do it just to be "cool" but because they expect to recoup what it costs. I would be glad to be proven wrong in certain individual cases, but this is how the system works in general. And besides, wouldn't you rather have an open source program drawing your maps? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: tomtom on the Neo1973
Thomas Gstädtner wrote: Well, this answer is not too bad and maybe better than expected. "will keep an eye on it" could mean, that TomTom will wait and see how the first OpenMoko Phones (Neo1973 Phase 2) sell. If the sales are ok, maybe they release their software for OpenMoko. I think you're right; after the first 250,000 or so Neo 1973 phones have been sold, they *may* look again. There are currently under 350 signups, so I wouldn't hold my breath if I were you. If you just want to use a $350 Neo as a $200 GPS, you might as well spend the time on a mashup of RoadMap and OpenStreetMap. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: tomtom on the Neo1973
Hi, you are right. I hope they change that information in the future :) With kind regards, Patrick Beck Am Dienstag, den 29.05.2007, 21:55 +0200 schrieb Thomas Gstädtner: > Well, this answer is not too bad and maybe better than expected. > "will keep an eye on it" could mean, that TomTom will wait and see how > the first OpenMoko Phones (Neo1973 Phase 2) sell. > If the sales are ok, maybe they release their software for OpenMoko. > ___ > 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
Imho it would be fantastic to have 2 navkeys at the right side of the phone to use dasher in the 1D-mode. So it could be possible to write texts using the right thumb what means typing with only one hand would be possible. A touchpad like seen on devices like the Cowon iAudio 6 or the Creative Zen-Touch-Series would be even better. Btw: I tried dasher for some minutes and its a bit hard at the beginning. After 5-10 mins of training it works very well! ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Fwd: tomtom on the Neo1973
Well, this answer is not too bad and maybe better than expected. "will keep an eye on it" could mean, that TomTom will wait and see how the first OpenMoko Phones (Neo1973 Phase 2) sell. If the sales are ok, maybe they release their software for OpenMoko. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New CPU
On Tuesday 29 May 2007 19:52:20 Crane, Matthew wrote: > For a viable commercial product I would expect the CPU to be first of all > the cheapest one that meets the minimal horsepower requirements, and > obviously other considerations, such as power consumption. From the page, the newly suggested SoC is very new, in fact newer than the original release date for the Neo1973. I don't think anyone at FIC would consider swapping out such a crucial element of the system at this stage of development, even if it would be cheaper and faster and more energy efficient at the same time. > Would you prefer to run Microsoft office for 30s or have your battery last > for a week? I would need to check the specs for details, but the newer core runs is fabricated in 0.13u instead of 0.18u and needs 1.3V+ instead of 1.8V+, those are actually signs that this core does not necessarily consume more power even though it has more MHz (also take into account improved power saving schemes). Also #2, MHz do not indicate speed. They indicate clock rate. 266MHz could be not enough and plenty at the same time depending on what you do with it and what the underlying architecture is. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re:information efficient text enty using dasher
Peter Hoffmann writes: >Hi > >i just stumbled over a video at the google talks series[0] about >information-efficient text entry using dasher[1]. > >I think this is quite an interesting input method for mobile devices >with touch screens or motion sensors. And it is open source and its user >interface is based on gtk. Interesting, yes -- there's a demo at http://www.inference.phy.cam.ac.uk/dasher/TryJavaDasherNow.html My experience (granted, using mouse rather than stylus) was that it was pretty hard to actually use. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tomtom on the Neo1973
Hello, i have now a answer from the TomTom support. It takes a longer time because the normal german TomTom Support could not answer my question and so i musst ask TomTom Pro. In addition i had not many time in the last months - Sorry. Now the answer from TomTom: Dear Mr. Beck, Currently TomTom has no plans to extend our navigation software to other platforms. However the Openmoko is an interesting development and we will keep an eye on it to see how this project evolves into the future. With kind regards, The TomTom PRO support team That is a bad Answer, but i hope TomTom change this information in the future. Greats Patrick Beck Am Samstag, den 31.03.2007, 14:37 +0200 schrieb Patrick Beck: > Hello, > > i follow the deployment of the Neo1973 and Openmoko since they become > public. > > I have discussed with a few others on the IRC, about the Idea to use > tomtom on the Neo1973. I think it will be very cool :) I had no problem > to pay money for a good software and rich in detail maps. It is hard > work to create good maps (see http://www.openstreetmap.org). > > When many people want to use tomtom on the Neo1973, it would be a good > precondition to assure tomtom from this idea to sell tomtom for the > Openmoko platform. tomtom devices already run under linux, so i think it > will not so hard to port it on Openmoko. > > My question is now => How we should ask tomtom? I think it will good > when a company or the intern developer of openmoko can ask. Beside the > company, all interested can ask tomtom. So they can see that we would > run tomtom on openmoko :) > > I hope that i'am not the only one who would run tomtom on the > Neo1973 ;) > > Greats Patrick Beck > > > > ___ > 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
Crane, Matthew schrieb: > Dasher is very neat, seems the method would be well suited to a wheel > button. I wonder if theres a method of entering text that would be well > suited to messaging but still handsfree. Voice recognition is the only > thing I could think of. The guy controlled dasher with breathing and a special belt and also with moving his head/eyes and a camera. But I don't think these techniques are very convenient for a mobile phone. Regards Peter ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: information efficient text enty using dasher
Dasher is very neat, seems the method would be well suited to a wheel button. I wonder if theres a method of entering text that would be well suited to messaging but still handsfree. Voice recognition is the only thing I could think of. Matt ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New CPU
ti, 2007-05-29 kello 13:13 -0400, Varga-Háli Dániel kirjoitti: > I don't know if there were any discussion about this. Today I was > looking at the processor and I saw (sadly) that it's got only > 200-266MHz. Do you think it is going to enough? Second-hand reports from those lucky enough to have phones indicate that the current software could use optimizing to run on it nicely. OTOH, it's apparently just about video capable, which is nice: http://wiki.openmoko.org/wiki/Video_Player > I am guessing that the core team is planning to put a faster CPU in. It's been mentioned that the P1+/2 revision will likely have a faster CPU; final specs have been promised at the same time P1 sales will start, hopefully soon :] -- Mikko Rauhala - [EMAIL PROTECTED] - http://www.iki.fi/mjr/> Transhumanist - WTA member - http://www.transhumanism.org/> Singularitarian - SIAI supporter - http://www.singinst.org/> ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: information efficient text enty using dasher
Paul Jimenez schrieb: > On Tuesday, May 29, 2007, Peter Hoffmann writes: >> Hi >> >> i just stumbled over a video at the google talks series[0] about >> information-efficient text entry using dasher[1]. >> >> I think this is quite an interesting input method for mobile devices >> with touch screens or motion sensors. And it is open source and its user >> interface is based on gtk. >> >> An other great point is that it is not only limited to english text, but >> you an use any input language/alphabet you want. >> >> >> I'm looking forward to test it on a neo. What do you think? >> >> >> Regards Peter >> >> [0] http://video.google.com/videoplay?docid=5078334075080674416 >> [1] http://www.inference.phy.cam.ac.uk/dasher/ > > > I think you should've searched the wiki :) > http://wiki.openmoko.org/wiki/Wishlist:Text_Input > lists Dasher as only one of over a dozen different wishlisted > input methods. > > --pj I knew the text_input section in the wiki and added the link to the video . But I found the presentation so interesting to share it with the list too. Regards Peter ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: information efficient text enty using dasher
On Tuesday, May 29, 2007, Peter Hoffmann writes: >Hi > >i just stumbled over a video at the google talks series[0] about >information-efficient text entry using dasher[1]. > >I think this is quite an interesting input method for mobile devices >with touch screens or motion sensors. And it is open source and its user >interface is based on gtk. > >An other great point is that it is not only limited to english text, but >you an use any input language/alphabet you want. > > >I'm looking forward to test it on a neo. What do you think? > > >Regards Peter > >[0] http://video.google.com/videoplay?docid=5078334075080674416 >[1] http://www.inference.phy.cam.ac.uk/dasher/ I think you should've searched the wiki :) http://wiki.openmoko.org/wiki/Wishlist:Text_Input lists Dasher as only one of over a dozen different wishlisted input methods. --pj ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
information efficient text enty using dasher
Hi i just stumbled over a video at the google talks series[0] about information-efficient text entry using dasher[1]. I think this is quite an interesting input method for mobile devices with touch screens or motion sensors. And it is open source and its user interface is based on gtk. An other great point is that it is not only limited to english text, but you an use any input language/alphabet you want. I'm looking forward to test it on a neo. What do you think? Regards Peter [0] http://video.google.com/videoplay?docid=5078334075080674416 [1] http://www.inference.phy.cam.ac.uk/dasher/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New CPU
Hi! I don't know if there were any discussion about this. Today I was looking at the processor and I saw (sadly) that it's got only 200-266MHz. Do you think it is going to enough? I get the info from: http://wiki.openmoko.org/wiki/Neo1973_Hardware#Processor I am guessing that the core team is planning to put a faster CPU in. Do you think, that this CPU would be better? http://www.samsung.com/products/semiconductor/MobileSoC/ApplicationProcessor/ARM9Series/S3C2443/S3C2443.htm What CPU are they planning to use? Dan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS+sms apps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 10-15c/SMS => that's about 60-90c per KB. Or 600-900$ per MB. Don't think that GPRS is THAT expensive even in Canada. Andreas Crane, Matthew wrote: > Ok, yea, they aren't often free, but they are often free to send even > with the basic plans. In the case of an application where it's sending > to a central server and notifications go out much more rarely, then free > to send is preferable. I think the basic plans often charge 10-15c. > For reference, Canadian $ getting closet to parity with USD lately. > > Matt > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Mikko J > Rauhala > Sent: Tuesday, May 29, 2007 9:56 AM > To: community@lists.openmoko.org > Subject: RE: GPS+sms apps > > On ti, 2007-05-29 at 09:15 -0400, Crane, Matthew wrote: >> I guess SMS is generally more accessable and tends to be a lot > cheaper, >> often free, in Toronto and most of Canada. > > I didn't know SMS are often free; here they cost a bundle, though a bit > less if you take a bulk deal in your monthly fees. OTOH, here we have > quite affordable no-limit GPRS(/EDGE/UMTS). > > Clearly it would be good for a locator service to be able to communicate > via both methods, depending on what kind of a mobile plan the user has. > > As for availability, for a GPRS-preferred user of such a service you > could pretty much assume that they are connected whenever the phone is > on and has coverage, so not that different from SMS... > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXD1jHJdudm4KnO0RApWlAKDofqLqU+WFF9Tk3YWJxrlQBtMMJQCgz05Y HoAmLspdqCph53ysk+UV6g8= =PN0Q -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: GPS+sms apps
Ok, yea, they aren't often free, but they are often free to send even with the basic plans. In the case of an application where it's sending to a central server and notifications go out much more rarely, then free to send is preferable. I think the basic plans often charge 10-15c. For reference, Canadian $ getting closet to parity with USD lately. Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mikko J Rauhala Sent: Tuesday, May 29, 2007 9:56 AM To: community@lists.openmoko.org Subject: RE: GPS+sms apps On ti, 2007-05-29 at 09:15 -0400, Crane, Matthew wrote: > I guess SMS is generally more accessable and tends to be a lot cheaper, > often free, in Toronto and most of Canada. I didn't know SMS are often free; here they cost a bundle, though a bit less if you take a bulk deal in your monthly fees. OTOH, here we have quite affordable no-limit GPRS(/EDGE/UMTS). Clearly it would be good for a locator service to be able to communicate via both methods, depending on what kind of a mobile plan the user has. As for availability, for a GPRS-preferred user of such a service you could pretty much assume that they are connected whenever the phone is on and has coverage, so not that different from SMS... -- Mikko J Rauhala <[EMAIL PROTECTED]> University of Helsinki ___ 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: GPS+sms apps
On ti, 2007-05-29 at 09:15 -0400, Crane, Matthew wrote: > I guess SMS is generally more accessable and tends to be a lot cheaper, > often free, in Toronto and most of Canada. I didn't know SMS are often free; here they cost a bundle, though a bit less if you take a bulk deal in your monthly fees. OTOH, here we have quite affordable no-limit GPRS(/EDGE/UMTS). Clearly it would be good for a locator service to be able to communicate via both methods, depending on what kind of a mobile plan the user has. As for availability, for a GPRS-preferred user of such a service you could pretty much assume that they are connected whenever the phone is on and has coverage, so not that different from SMS... -- Mikko J Rauhala <[EMAIL PROTECTED]> University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS+sms apps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, it's a general problem. Depending upon your phone plan, using SMS might make sense or not. If SMS are free, that's nice, although I doubt you'll manage to run a ppp session with mtu 150 over it :-P Generically speaking, SMS are certainly more complicated to deal with: GPRS is simple TCP/IP. SMS are special modem commands to the GSM module. GPRS means that basically any server connected to the Internet can probably communicate with the phone. SMS means the server needs either some special Internet service to send and receive!!! SMS, or a not exactly free-of-costs GSM module. In practice you would need completly free and unlimited SMS so that it makes somehow sense. Even 1ct per SMS ruins the economy, => US$/CDN$/EUR 70 per MB (depending if the cent was US/CDN/EUR *g*), combined with an extremly low bandwidth (there is a limit how many SMS you can send/receive per minute with a GSM module). > I guess SMS is generally more accessable and tends to be a lot cheaper, It depends. E.g. my German calling plan includes an UMTS flatrate, but SMS are 30ct per piece. At least with UMTS + Opera on the phone the sms.at website (that allows me to send cheap/free SMS) is usuable well enough :) My Austrian calling plan has 250MB UMTS, GPRS flatrate (basically UMTS with a speed limit after the included MB), and 1000 SMS included. That makes sending data via GPRS the safer option, cost wise. > often free, in Toronto and most of Canada. Phones could transmit > position continuously to a central server, or some centralized > mechanisim, and I'm thinking it would be much easier for a centralized > server program to notify phones reliably with SMS, rather then depend on > a data connection. SMS are not reliable. OTOH, you can get a send report, although these often cost extra :( Andreas > > Basically by using SMS it would be a more accesable and reliable > application that could be run continously by the participants. Tie it > into a social networking site maybe too. > > Matt > > > > > -Original Message- > From: Dean Collins [mailto:[EMAIL PROTECTED] > Sent: Monday, May 28, 2007 5:16 PM > To: Crane, Matthew; OpenMoko > Subject: RE: GPS+sms apps > > Why would you need SMS - if you are running a data plan already to track > cell tower and relative position to other Neo users then you may as well > make it a self contained application. > > > > Regards, > > Dean Collins > Cognation Pty Ltd > [EMAIL PROTECTED] > > > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:community- >> [EMAIL PROTECTED] On Behalf Of Crane, Matthew >> Sent: Monday, 28 May 2007 4:57 PM >> To: OpenMoko >> Subject: GPS+sms apps >> >> >> Is there any existing application which combine sms messaging and GPS? >> It would be pretty cool to get automated alerts whenever a particular >> person is nearby, through a central machine (phone, desktop). Or to > use >> some sort of automated homing application, where two people are able > to >> lock to each other and the phone guides them, notifying the other > device >> when the route or position has changed. >> >> Matt >> >> ___ >> 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXDBqHJdudm4KnO0RAuBaAJ9RbeGxNpLgqVBz+YtZ9TM3hmL0mACeOTV7 YaYmRlHlU/iqDp0Oz2Hx4W4= =/JXJ -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: GPS+sms apps
I guess SMS is generally more accessable and tends to be a lot cheaper, often free, in Toronto and most of Canada. Phones could transmit position continuously to a central server, or some centralized mechanisim, and I'm thinking it would be much easier for a centralized server program to notify phones reliably with SMS, rather then depend on a data connection. Basically by using SMS it would be a more accesable and reliable application that could be run continously by the participants. Tie it into a social networking site maybe too. Matt -Original Message- From: Dean Collins [mailto:[EMAIL PROTECTED] Sent: Monday, May 28, 2007 5:16 PM To: Crane, Matthew; OpenMoko Subject: RE: GPS+sms apps Why would you need SMS - if you are running a data plan already to track cell tower and relative position to other Neo users then you may as well make it a self contained application. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:community- > [EMAIL PROTECTED] On Behalf Of Crane, Matthew > Sent: Monday, 28 May 2007 4:57 PM > To: OpenMoko > Subject: GPS+sms apps > > > Is there any existing application which combine sms messaging and GPS? > It would be pretty cool to get automated alerts whenever a particular > person is nearby, through a central machine (phone, desktop). Or to use > some sort of automated homing application, where two people are able to > lock to each other and the phone guides them, notifying the other device > when the route or position has changed. > > Matt > > ___ > 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: Ruby for OpenMoko - got it small
Hi, depending on what you eventually want to do, you might be interested by Lua [http://www.lua.org] It's really easy to embed (I run it on a proprietary platform, in 150KB flash + 100KB RAM, running rather big apps written in pure Lua, all bindings to GSM/GPRS, TCP/IP etc., admittedly with a few tweaks in memory management). And it's blazingly faster than Ruby. Wrt Ruby, the only thing you might miss in the core is that Lua's object paradigm is lower level (prototype based); OTOH, you might well fall in love with its metaprogramming abilities! Of course, if you have plenty of libs in Ruby suited to the applications you have in mind, the platform is more important than the language. But what Ruby libs would you plan to leverage in your typical openmoko application? Would it be hard to find good alternatives on luaforge [ http://www.luaforge.net]? -- Fabien. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
