Hi, I heard a bit of a radio interview with a Jason Burton of
Alzheimer's Australia Western Australia who was working on a project to
use GPS enabled handsets as locators for people with dementia (who would
obviously need to be carrying the handset and have GPS reception for the
idea to work).
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
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
-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
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.
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,
-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
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
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
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
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
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
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
___
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
[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
--
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
29 matches
Mail list logo
