| 15:19.28 | *** join/#maemo infobot (ibot@rikers.org) |
| 15:19.28 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | "firmware" see ~lf (or ~tabletsdev ~combined ~emmc ~flasher) sdk: ~sb | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog http://maemo.cloud-7.de/irclogs/freenode/_maemo/latest.log.html | #maemo-ssu is where the (few) devels and maintainers of the maemo-future meet |
| 15:19.28 | *** mode/#maemo [+v infobot] by ChanServ |
| 15:19.32 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 15:20.40 | *** join/#maemo Kabouik (~kabouik@2a01cb008023010094ce3e4639dff0fa.ipv6.abo.wanadoo.fr) |
| 15:31.46 | sicelo | re - supl-proxy : i'm having difficulty to get consistent results with it - maemo seems to make only one a-gps request in a looong time. Hence even daemonizing the proxy might have limited benefits :-( |
| 15:32.07 | *** join/#maemo sunshavi (~user@190.239.244.220) |
| 15:32.35 | sicelo | in all my tried today, i haven't been able to get an a-gps lock |
| 15:48.10 | sicelo | or is there a known good way to nudge Maemo into making more supl requests? |
| 15:49.13 | KotCzarny | maybe it uses supl when you lose signal? |
| 15:53.54 | sicelo | i never got a lock though, so i would expect/hope it would make more supl requests, but thatwas not to be. |
| 16:14.19 | bencoh | sicelo: :( |
| 16:15.09 | bencoh | did you run supl-proxy before running gps customer app? |
| 16:16.00 | bencoh | and no, I wasn't really able to understand when/why it makes supl requests |
| 16:16.16 | bencoh | although I far as I can tell, requests come from the modem itself |
| 16:16.42 | bencoh | the host cpu only wraps/forwards it, and returns back rrlp response |
| 16:16.56 | bencoh | (or supl, dunno, in which form it returns it) |
| 16:27.20 | sicelo | yes i ran it before, and when it exited after providing data, i restarted it (supl-proxy) - no further requests were made even though i never got a lock. closing an re-opening gps consumer didn't make any difference either (i used Location Test application, and I was outside) |
| 16:57.10 | bencoh | then my first impression was a good one, and we still don't have a proper fix I guess |
| 16:58.34 | bencoh | ack then I suspected the connexion between proxy and google broke in the middle (with part of the needed bits of information missing / waiting to be tranfered) |
| 16:59.14 | bencoh | then once outside I got a quick fix and thought it still worked anyway |
| 17:13.21 | *** join/#maemo jskarvad (jskarvad@redhat/jskarvad) |
| 19:05.29 | DocScrutinizer05 | bencoh: you're most likely right about how host CPU gets (not) involved into SUPL and RRLP |
| 19:06.24 | DocScrutinizer05 | RRLP is basically "supl on control tier" AIUI |
| 19:06.34 | DocScrutinizer05 | ~gsm-agps |
| 19:06.35 | infobot | RRLP is the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://osmocom.org/projects/security/wiki/RRLP |
| 19:07.33 | DocScrutinizer05 | sorry, "signaling plane" not "control tier" |
| 19:08.56 | DocScrutinizer05 | for RRLP to work, modem needs to identify/log-in to a cellular carrier network |
| 19:09.58 | DocScrutinizer05 | giben that, and carrier supporting RRLP, I get fix within an instant - like less than 5s. Particularly thanks to U-TDOA |
| 19:10.05 | DocScrutinizer05 | even indoors |
| 19:10.30 | DocScrutinizer05 | ~u-tdoa |
| 19:10.31 | infobot | well, u-tdoa is http://en.wikipedia.org/wiki/U-TDOA |
| 19:16.09 | *** join/#maemo nslu2-log (~nslu2-log@23.141.224.193) |
| 19:20.15 | *** join/#maemo pcfe (~pcfe@2a02:8109:b6c0:1062:beee:7bff:fed9:8f1b) |
| 19:20.24 | *** join/#maemo pcfe (~pcfe@redhat/pcfe) |
| 19:43.20 | DocScrutinizer05 | technically U-TDOA can provide a XY location fix, and - exploiting doppler effect - even a XY velocity vector dix, within <<1s. Where U-TDOA epically fails is any Z / altitude measurement, due to all BTS being basically located in one plane and probably also same like the ME |
| 19:46.08 | DocScrutinizer05 | so the altitude of ME has no impact on timing observed by the Location Measurement Units in BTS |
| 19:46.34 | *** join/#maemo saidinesh5 (~quassel@minad.de) |
| 19:47.25 | DocScrutinizer05 | you'd need LMUs on different altitudes to measure altitude of ME |
| 19:48.36 | DocScrutinizer05 | for GPS the SVs have different apparent altitude thanks to the sphere they move in |
| 20:13.03 | *** join/#maemo saidinesh5 (~quassel@minad.de) |
| 20:27.26 | *** join/#maemo pagurus` (~user@i59F7C517.versanet.de) |
| 20:30.59 | *** join/#maemo Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 20:34.55 | *** join/#maemo lukedashjr (~luke-jr@unaffiliated/luke-jr) |
| 20:39.41 | *** join/#maemo luke-jr (~luke-jr@unaffiliated/luke-jr) |
| 20:42.52 | *** join/#maemo luke-jr (~luke-jr@unaffiliated/luke-jr) |
| 20:50.21 | *** join/#maemo luke-jr (~luke-jr@unaffiliated/luke-jr) |
| 22:44.01 | *** join/#maemo Kilroo (~Kilroo@173.94.24.151) |
| 23:45.50 | *** join/#maemo troulouliou_div2 (~troulouli@unaffiliated/troulouliou-div2/x-0271439) |