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 :-( | 17:31 |
---|---|---|
sicelo | in all my tried today, i haven't been able to get an a-gps lock | 17:32 |
sicelo | or is there a known good way to nudge Maemo into making more supl requests? | 17:48 |
KotCzarny | maybe it uses supl when you lose signal? | 17:49 |
sicelo | i never got a lock though, so i would expect/hope it would make more supl requests, but thatwas not to be. | 17:53 |
bencoh | sicelo: :( | 18:14 |
bencoh | did you run supl-proxy before running gps customer app? | 18:15 |
bencoh | and no, I wasn't really able to understand when/why it makes supl requests | 18:16 |
bencoh | although I far as I can tell, requests come from the modem itself | 18:16 |
bencoh | the host cpu only wraps/forwards it, and returns back rrlp response | 18:16 |
bencoh | (or supl, dunno, in which form it returns it) | 18:16 |
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) | 18:27 |
bencoh | then my first impression was a good one, and we still don't have a proper fix I guess | 18:57 |
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) | 18:58 |
bencoh | then once outside I got a quick fix and thought it still worked anyway | 18:59 |
DocScrutinizer05 | bencoh: you're most likely right about how host CPU gets (not) involved into SUPL and RRLP | 21:05 |
DocScrutinizer05 | RRLP is basically "supl on control tier" AIUI | 21:06 |
DocScrutinizer05 | ~gsm-agps | 21:06 |
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 | 21:06 |
DocScrutinizer05 | sorry, "signaling plane" not "control tier" | 21:07 |
DocScrutinizer05 | for RRLP to work, modem needs to identify/log-in to a cellular carrier network | 21:08 |
DocScrutinizer05 | giben that, and carrier supporting RRLP, I get fix within an instant - like less than 5s. Particularly thanks to U-TDOA | 21:09 |
DocScrutinizer05 | even indoors | 21:10 |
DocScrutinizer05 | ~u-tdoa | 21:10 |
infobot | well, u-tdoa is http://en.wikipedia.org/wiki/U-TDOA | 21:10 |
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 | 21:43 |
DocScrutinizer05 | so the altitude of ME has no impact on timing observed by the Location Measurement Units in BTS | 21:46 |
DocScrutinizer05 | you'd need LMUs on different altitudes to measure altitude of ME | 21:47 |
DocScrutinizer05 | for GPS the SVs have different apparent altitude thanks to the sphere they move in | 21:48 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!