<table cellspacing='0' cellpadding='0' border='0' ><tr><td valign='top' style='font: inherit;'>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: <br><br>- 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. <br><br>- 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). <br><br>- 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). <br><br>- 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). <br><br>- 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). <br><br><br>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!). <br><br><br>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). <br><br><br>--- El <b>mar, 24/6/08, Yorick Matthys <i><yorick_matthys@hotmail.com></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">De: Yorick Matthys <yorick_matthys@hotmail.com><br>Asunto: GPS<br>Para: "community@openmoko" <community@lists.openmoko.org><br>Fecha: martes, 24 junio, 2008 10:36<br><br><pre>Jisakiel wrote:<br><br>>Let's see if I understood
correctly the concepts involved here, as I am<br>still a little bit confused...<br>><br>>- TTFF is when no almanac data is available. Unlike what's specified in<br>http://wiki.openmoko.org/wiki/Neo_FreeRunner , is not 40 seconds but 12 minutes<br>(no>small difference).<br>>- TTFF shouldn't happen almost never, given that mobile phone is always<br>-but it's first boot *ever*- in normal state as defined here :<br>http://en.wikipedia.org<br>>/wiki/Time_to_first_fix . Unless we have moved in a 100km radius without<br>gps enabled, mobile phone does not have the correct time, we are in a car /<br>train,>and (dunnow if that's an AND or OR) no previous almanac<br>available, fixes should be a lot quicker. As in, how much?<br>>- AGPS should make ¿everything? ¿TTFF only? by downloading a small data<br>package.<br>><br>>My questions, then:<br>><br>>- AGPS can be served by the gsm network without data transfer costs? I<br>mean:
does it *need* to download it from the internet (with its GPRS<br>associated>connection and outrageous prices here in Spain), or is it<br>transferred for free from the GSM operator? I understand this piece of<br>information to be common to>every GPS phone, not just openmoko...?<br>>- In normal conditions a fix is quite quick (as in 2 or 3 seconds) and not<br>too "expensive" in terms of battery or processing. Is that true?<br>>- If I get in a car fixes get slower unless I have gps constantly on (which<br>should eat the battery fast).<br>>- Should I travel without network coverage (as in: by tube), when arrived<br>at destiny fix will be slower. How much slower? Does AGPS help here?<br>>- Is it possible to get some triangulation info from the GSM towers the<br>phone is connected to? Possible as in "here's how on the<br>openmoko", not as in>"theoretically" ;), which I know that it<br>is -my symbian phone does it, I remember some profile
software which used that.<br>><br>><br>- TTFF is time to first fix, and it does not only apply to when there is no<br>almanac data (http://en.wikipedia.org/wiki/Time_to_first_fix, you found the<br>page but i think you didn't read it carefully)<br>- TTFF happens every time you power on the gps module<br>- AGPS decreases the TTFF time<br><br>Your questions:<br>- AGPS can NOT be served by the gsm network without data transfer costs. But<br>you can also download it from your home network<br>you can use AGPS online or offline. Take a look at the bottom of<br>http://www.u-blox.com/technology/assistnow/<br>online: valid max 4hours, offline valid max 14days<br>I am not sure if the offline can work in the freerunner (if it has EPROM it<br>will work, otherwise maybe not, I can't find it in the wiki so I guess it<br>has none)<br>- normal conditions: take a look page 2
of<br>http://www.u-blox.com/products/Product_Summaries/ATR0630_35_Chip_Prod_Summary(GPS.G4-X-07008).pdf<br>- when you travel by tube i think you will get a fix very soon (If you had a<br>fix before you entered the tube)<br>- somebody correct me if I'm wrong, but I don't think it has been<br>implemented for the freerunner (yet)<br><br><br>_________________________________________________________________<br>Probeer Live Search: de zoekmachine van de makers van MSN! <br>http://www.live.com/?searchOnly=true<br>_______________________________________________<br>Openmoko community mailing list<br>community@lists.openmoko.org<br>http://lists.openmoko.org/mailman/listinfo/community</pre></blockquote></td></tr></table><br>
<hr size=1><br><font face="Verdana" size="-2">Enviado desde <a href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52431/*http://es.docs.yahoo.com/mail/overview/index.html">Correo Yahoo!</a><br>La bandeja de entrada más inteligente.<br></font>