Hmmm shame AGPS is not yet implemented, as 14d seems pretty reasonable as a
requisite, as well as 30 seconds to fix (I somehow doubt it would fix as quick
inside a building or in the city, but...). For the project to be viable I guess
we (as we are 3 on that university project) would have to implement it first,
which is some noticeable setback for our available time (because we think time
to market counts for our idea to suceed). Anyhow:
- Is it possible then to fetch approximate position from the associated GSM
towers then? I guess it depends on the subset of commands the chip implements,
but I didn't have the time to read over those *extensive* documents as I'm
still finishing my exams. I somehow suspect though that the GSM commands do not
cover for that, and that'd be proprietary for the chip... Please correct me if
I'm mistaken. I have no idea as well on how precise is that.
- What events can be programmed to wake up the phone from standby? Not so much
related, but for instance if accelerometers were somehow "autonomous" or
programmable from the main CPU, they could wake up the phone if tapped a
ceirtain way as to "wake it up". Say, with three subtle touches on a side, or
perhaps shaking it three times... I'm pretty sure that's science-fiction for
now ;), but it's worth asking. I'm guessing cron events can conceptually wake
it up as well? (I'm aware that no cron daemon is still present, at least in the
non-qtopia side).
- Still no information on impact on the battery life for the GPS fix. I seem to
remember from the lists that geocaching (always-on) was quite draining (as in
less-than-one-day standby time, which would be our absolute minimum); that
would leave us with sleeping down and up periodically; but we'd need enough
granularity for our purposes (say, no more than 5 minutes between positions as
to react somehow sloppily to our environment... so if a whole minute is spent
just trying to figure out where we are is not that much useful at all).
- Accelerometers can also help if not too draining on the battery:
while we are not moving, don't even try to get a new position. That,
however, would seem to prevent the phone going to standby, which again
would be hard on the battery (perhaps harder than just waking up every
¿minute? and getting a new fix, or just not worth vs leaving GPS always on).
- Any idea on how taxing is to scan the wifi for available networks? That could
also give us valuable clues on location (in the Uni => "eduroam"; while at home
the private WLAN, for instance), as well as allowing to base profiles on them
(when in the uni, keep the mobile silent; when at home, try to sync to the
computer and use voip, etc).
We think our main viability constraint would be the omnipresent battery life,
that's why all our interest on those tradeoffs. Unstability and incompleteness
of the APIs also make openmoko a risky option for us; we have to analize
carefully the current state of the software (using qtopia would be perfectly
fine as well if complete enough, though we'd prefer the "native" api if it
would be enough done on time, as we're more familiar with GTK and glade). On
the good side opensource would allow us to extend PIM libraries, base
components, or add daemons and additional APIs to the phone (such as
"location"), which so far I believe none of the alternatives allow ;) (not even
on Android, I'm guessing!).
BTW is glade usable on the current stack? We managed to get some prototypes
quite quickly with pygtk and glade on the desktop this year for unrelated
projects... Don't know if that experience would be appliable to the phone,
though (not sure if glade exists, or its components, or what's required to port
code, etc).
--- El mar, 24/6/08, Yorick Matthys <[EMAIL PROTECTED]> escribió:
De: Yorick Matthys <[EMAIL PROTECTED]>
Asunto: GPS
Para: "[EMAIL PROTECTED]" <[email protected]>
Fecha: martes, 24 junio, 2008 10:36
Jisakiel wrote:
>Let's see if I understood correctly the concepts involved here, as I am
still a little bit confused...
>
>- TTFF is when no almanac data is available. Unlike what's specified in
http://wiki.openmoko.org/wiki/Neo_FreeRunner , is not 40 seconds but 12 minutes
(no>small difference).
>- TTFF shouldn't happen almost never, given that mobile phone is always
-but it's first boot *ever*- in normal state as defined here :
http://en.wikipedia.org
>/wiki/Time_to_first_fix . Unless we have moved in a 100km radius without
gps enabled, mobile phone does not have the correct time, we are in a car /
train,>and (dunnow if that's an AND or OR) no previous almanac
available, fixes should be a lot quicker. As in, how much?
>- AGPS should make ¿everything? ¿TTFF only? by downloading a small data
package.
>
>My questions, then:
>
>- AGPS can be served by the gsm network without data transfer costs? I
mean: does it *need* to download it from the internet (with its GPRS
associated>connection and outrageous prices here in Spain), or is it
transferred for free from the GSM operator? I understand this piece of
information to be common to>every GPS phone, not just openmoko...?
>- In normal conditions a fix is quite quick (as in 2 or 3 seconds) and not
too "expensive" in terms of battery or processing. Is that true?
>- If I get in a car fixes get slower unless I have gps constantly on (which
should eat the battery fast).
>- Should I travel without network coverage (as in: by tube), when arrived
at destiny fix will be slower. How much slower? Does AGPS help here?
>- Is it possible to get some triangulation info from the GSM towers the
phone is connected to? Possible as in "here's how on the
openmoko", not as in>"theoretically" ;), which I know that it
is -my symbian phone does it, I remember some profile software which used that.
>
>
- TTFF is time to first fix, and it does not only apply to when there is no
almanac data (http://en.wikipedia.org/wiki/Time_to_first_fix, you found the
page but i think you didn't read it carefully)
- TTFF happens every time you power on the gps module
- AGPS decreases the TTFF time
Your questions:
- AGPS can NOT be served by the gsm network without data transfer costs. But
you can also download it from your home network
you can use AGPS online or offline. Take a look at the bottom of
http://www.u-blox.com/technology/assistnow/
online: valid max 4hours, offline valid max 14days
I am not sure if the offline can work in the freerunner (if it has EPROM it
will work, otherwise maybe not, I can't find it in the wiki so I guess it
has none)
- normal conditions: take a look page 2 of
http://www.u-blox.com/products/Product_Summaries/ATR0630_35_Chip_Prod_Summary(GPS.G4-X-07008).pdf
- when you travel by tube i think you will get a fix very soon (If you had a
fix before you entered the tube)
- somebody correct me if I'm wrong, but I don't think it has been
implemented for the freerunner (yet)
_________________________________________________________________
Probeer Live Search: de zoekmachine van de makers van MSN!
http://www.live.com/?searchOnly=true
_______________________________________________
Openmoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
______________________________________________
Enviado desde Correo Yahoo! La bandeja de entrada más inteligente._______________________________________________
Openmoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
