**** BEGIN LOGGING AT Sat May 25 02:59:58 2019
**** BEGIN LOGGING AT Thu May 30 09:28:10 2019
**** BEGIN LOGGING AT Thu May 30 11:38:25 2019
May 30 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 :-(
May 30 15:32:35 <sicelo> in all my tried today, i haven't been able to get an a-gps lock
May 30 15:48:10 <sicelo> or is there a known good way to nudge Maemo into making more supl requests?
May 30 15:49:13 <KotCzarny> maybe it uses supl when you lose signal?
May 30 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. 
May 30 16:14:19 <bencoh> sicelo: :(
May 30 16:15:09 <bencoh> did you run supl-proxy before running gps customer app?
May 30 16:16:00 <bencoh> and no, I wasn't really able to understand when/why it makes supl requests
May 30 16:16:16 <bencoh> although I far as I can tell, requests come from the modem itself
May 30 16:16:41 <bencoh> the host cpu only wraps/forwards it, and returns back rrlp response
May 30 16:16:56 <bencoh> (or supl, dunno, in which form it returns it)
May 30 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)
May 30 16:57:10 <bencoh> then my first impression was a good one, and we still don't have a proper fix I guess
May 30 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)
May 30 16:59:14 <bencoh> then once outside I got a quick fix and thought it still worked anyway
**** ENDING LOGGING AT Thu May 30 17:08:18 2019

**** BEGIN LOGGING AT Thu May 30 19:16:09 2019
May 30 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
May 30 19:46:08 <DocScrutinizer05> so the altitude of ME has no impact on timing observed by the Location Measurement Units in BTS
May 30 19:47:25 <DocScrutinizer05> you'd need LMUs on different altitudes to measure altitude of ME
May 30 19:48:36 <DocScrutinizer05> for GPS the SVs have different apparent altitude thanks to the sphere they move in
**** ENDING LOGGING AT Fri May 31 02:59:58 2019