is actually not gypsy. Rather (some) gypsy calls implemented as "location-daemon". location-daemon/gypsy gets spawned after an application requests GPS. How exactly - TBD.
Setting up GPSD with gpsfake on a VM
Install gpsd and gpsd-clients:
apt install gpsd gpsd-clients
Stop apparmor (for testing only!):
/etc/init.d/apparmor stop aa-teardown
And then you can run gpsfake using test files from the gpsd repo:
git clone https://github.com/maemo-leste-upstream-forks/pkg-gpsd gpsfake -c 1 pkg-gpsd/test/daemon/nokia-ld-4w.log
Then in another terminal, type:
And you should see the information from the GPS log be replayed.
(On combining multiple gps sources such as A-GPS/SUPL and gpsd) https://lists.gnu.org/archive/html/gpsd-dev/2012-07/msg00018.html(not actually relevant, A-GPS needs to fed to the GPS driver/subsystem, not merged as info into gpsd)
- supl implementation: https://github.com/tajuma/supl
Regarding Droid 4 GPS
17:05 < Wizzup> tmlind: wrt gps on the droid, you said there is currently a bug that allows opening /dev/gnss* only once? 17:09 < tmlind> Wizzup: i think that was a bug in gpsd, did not happen last time i tried. if you hit that one, opening secondary clients like gpspipe -R won't output anything 17:09 < Wizzup> ah, so it's not a kernel problem, ok 17:10 < Wizzup> once maemo-input-sounds is done (hopefully tonight) I will work on location stuff in case I can go on vacation and need gps, or until fmg is done with abook and we then look at rtcom 17:10 < Wizzup> in any case, I was wondering what the gps status is, but I think we'll start gpsd on demand, so that's fine 17:11 < Wizzup> from a pm pov, I assume closing the fd will stop gps recv? 17:11 < Wizzup> also, this is on the wiki: 22:30 < tmlind> hmm there's a probably kernel gnss bug for gsp access fyi, you can currently only open one connection before you have to restart gpsd :) 17:13 < tmlind> Wizzup: yeah so if hiking, you probably want to modprobe gnss_motmdm rate_ms=3000 or even higher to allow the soc to sleep inbetween 17:14 < tmlind> Wizzup: the default gpsd options only open device if there's a client and times out automatically 17:14 < Wizzup> interesting. 17:14 < Wizzup> regarding module - well noted 17:14 < Wizzup> I didn't know gpsd auto closed, that's nice. 17:15 < tmlind> i think i measured about 200 - 250 mW with gps enabled screen blanked etc
Regarding A-GPS in general, but also N900 and Droid 4 specifics
17:15 < Wizzup> also ran into this: https://lists.gnu.org/archive/html/gpsd-dev/2012-07/msg00018.html 17:15 < Entitlement> Wizzup - [ Re: [gpsd-dev] Using multiple location sources to improve accuracy and r ] 17:15 < Wizzup> (regarding agps) 17:15 < tmlind> Wizzup: yeah so don't enable gpsd -n option, that will keep the gps open 17:15 < Wizzup> looks like ESR suggests to write a daemon that sits in the middle and mixes in agps info 17:15 < Wizzup> ok 17:16 < Wizzup> regarding rate_ms, I wonder if it makes more sense to keep it lower until a proper fix is found 17:16 < Wizzup> although I suppose that's only the reporting rate, so it probably doesn't matter 17:16 < tmlind> yeah it defaults to 1s so just leave it out by default 17:16 < tmlind> it will be some generic option eventually and not a module param 17:17 -!- z3ntu_ [z3ntumatri@gateway/shell/matrix.org/x-lnssiqwycssoqteb] has quit [Quit: Idle for 30+ days] 17:18 < tmlind> not sure how much stuff i'll get done over next few months in general, but at some point i'm planning to continue on the droid4-agps tool.. 17:19 < Wizzup> tmlind: what would that do? 17:19 < Wizzup> I figured agps could be done via with https://github.com/tajuma/supl 17:19 < Entitlement> Wizzup - [ GitHub - tajuma/supl ] 17:19 < Wizzup> s/via with/with this/ 17:20 -!- peetah [~firstname.lastname@example.org] has joined #maemo-leste 17:22 < bencoh> (tested and more or less working on maemo5, btw) 17:22 < Wizzup> bencoh: just now? 17:22 < bencoh> no 17:22 < Wizzup> :) 17:23 < bencoh> I used it to proxify supl requests to google 17:23 < tmlind> Wizzup: hmm maybe not sure. in this case we need to download qcom provided up to date xtra2.bin file for the gnss, not sure if the older formats work at all for the gnss 17:25 < bencoh> tmlind: I'd tend to think you would need to keep gps "always on" before the first fix 17:25 < bencoh> otherwise you will never get enough information from satellites 17:25 < bencoh> (unless you have agps/supl, of course) 17:26 < Wizzup> tmlind: from what I can tell that tool just takes lac/mcc/mns and such (like we can get from ofono or from modem directly) and just calls to a SUPL service? 17:27 < bencoh> Wizzup: google would even return you a rough position with those 17:27 < tmlind> bencoh: yes it does that already automatically and won't start idling until the fix is done 17:27 < bencoh> tmlind: ah, I see 17:28 < tmlind> Wizzup: yeh i figured, not sure if the modem nvram settings for supl are working or not, i somehow have an impression they're only working for some older modems, could be wrong 17:28 < Wizzup> I don't know enough about AGPS clearly, but from what I currently understand, it's just a data connection to a server with some cell data 17:29 < Wizzup> so I am not sure what the modem would do specifically 17:29 < Wizzup> I suppose there are probably many "assisted" methods 17:29 < bencoh> Wizzup: you're supposed to receive orbital data / almanac 17:30 < Wizzup> ah 17:30 < bencoh> and feed it to the gps subsystem 17:30 < tmlind> yeah this xtra2.bin stuff is an almanac in some proprietary format for a week i think 17:30 < Wizzup> oh, right, to actually feed it 17:30 < Wizzup> I get it now. 17:30 < Wizzup> when I was searching for methods to tell gpsd about agps nothing turned out, explains it now 17:31 < Wizzup> s/turned out/turned up/ 17:31 < bencoh> iiuc on n900, the modem itself manages the supl connection; the location daemon only acts as a proxy to provide it a tcp connection 17:31 < Wizzup> ok, yeah, so for the n900 we will have to RE some stuff 17:31 < bencoh> yeah 17:31 < tmlind> bencoh: afaik also mdm6600 nvram has something for supl server, not sure if it works though 17:32 < tmlind> bencoh: if you want to try it, you can tweak the nvram values with tcmdrw on github.com/tmlind 17:32 < bencoh> tmlind: meaning implementing/RE-ing such a proxy would make sense for both platforms 17:33 < tmlind> bencoh: hmm proxy running where? on the device? 17:33 < bencoh> on n900/maemo5, yeah 17:33 < bencoh> iirc it is location-proxy (forked on demand I think) 17:33 < tmlind> well i think the modem uses the supl server directly probably based on some requirements from the ministry of silly walks 17:34 < Wizzup> bencoh: there is location-proxy and location-daemon btw 17:34 < bencoh> it does; the "proxy" only provides the modem with a mean to open a tcp socket and read/write to it 17:34 < bencoh> Wizzup: indeed 17:34 < Wizzup> if you have more info please share :) 17:34 < Wizzup> I can RE some stuff, but want to RE the right things only 17:35 < bencoh> I haven't toyed with those for quite some time, but lemme see 17:35 < tmlind> well the thing to try with droid4 mdm6600 would be to configure supl server in nvram, start modem data connection, then gps and see how fast it gets a fix 17:38 < tmlind> i'd try clearing openpst NV_AAGPS_XTRA_ENABLED_I value to try to disable xtra2.bin use, then try to configure whatever nvram values there might be for a supl server, sorry no idea what those entries might be but i see the dumps contain some url in hex format 17:40 < bencoh> Wizzup: see /usr/lib/liblas.so.0.0.0 17:41 < bencoh> especially the las_socket_* 17:41 < bencoh> location-proxy refers to those 17:42 < Wizzup> hm 32K 17:42 < Wizzup> this is likely all n900 specific though right? 17:42 < bencoh> Wizzup: http://pastebin.notk.org/pastebin.php?show=f7f7b371d 17:42 < Entitlement> bencoh - [ pastebin private pastebin - collaborative debugging tool ] 17:42 < bencoh> most likely n900-specific yeah 17:42 < tmlind> hmm so a quick search for the NV_AAGPS_XTRA_ENABLED_I points to some earlier pastebin page at https://pastebin.com/dyfsUcHc, maybe try configuring those and disable xtra stuff? 17:42 < Entitlement> tmlind - [ QPST 378 NV Items that are in i535 but NOT in i535 dev ed - Pastebin.com ] 17:43 < bencoh> tmlind: I don't think supl server address would go into nvram 17:43 < Wizzup> bencoh: ah, so you're suggesting we make some generic "how to write supl data to a modem" lib? 17:43 < bencoh> tmlind: well, unless it has a mean to actually ask for a specific supl server from the AP processor 17:43 < tmlind> bencoh: i'm pretty sure the uri goes to nvram, see NV_CGPS_UMTS_PDE_SERVER_ADDR_URL_I in the link above 17:43 < bencoh> oh 17:44 < bencoh> well, on n900/maemo5, the host gets to decide on that 17:44 < tmlind> ok 17:45 < bencoh> Wizzup: I guess we would want a "generic" glue lib with support for various (two?) platforms 17:45 < tmlind> bencoh: there seems to be a bunch PDE related nvram entries, see libopenpst dm_nv.h file 17:46 < bencoh> right 17:47 < bencoh> Actually I wonder if the supl connection would need to go through the host cpu at all on the mdm6600 17:47 < tmlind> bencoh: no afaik it can't 17:48 < bencoh> it might try and use the gprs/umts data channels 17:48 < tmlind> i think it has to 17:48 < bencoh> without even bothering with the host 17:48 < tmlind> right 17:48 < bencoh> it's a completely different design then 17:48 < bencoh> meaning it should work automagically once we setup pde server properly 17:49 < tmlind> yeah it should hopefully unless it's working only in the xtra2.bin mode 17:49 < bencoh> and that it'll stop working forever once supl servers break support for it 17:49 < tmlind> bencoh: so i did also a tool for the xtra2.bin stuff but it's not complete, also on my github page droid4-agps or something like that 17:49 < bencoh> (unlike n900, where we managed to somehow get some kind of support using supl-proxy from tajuma) 17:50 < tmlind> bencoh: at least the supl stuff is a standard format, let's hope it works :) 17:51 < bencoh> it's "standard" until google decides some input fields become mandatory 17:51 < bencoh> but yeah 17:51 < tmlind> i think there are other supl servers available too, right? 17:51 < Wizzup> bencoh: there were other supl servers I think 17:51 < bencoh> (I think that's the reason supl.google.com doesn't work on n900 without any proxy) 17:51 < Wizzup> bencoh: oh? 17:51 < bencoh> well, it depends on your phone service provider 17:52 < bencoh> vodaphone has (had?) one for their customers, but it's not available from outside their network 17:52 < bencoh> nokia died 17:52 < bencoh> I think sony had one, but ... 17:53 < bencoh> we could also run one, but we'd need to write a fair bit of code for that 17:53 < Wizzup> didn't see any code for it so far 17:53 < Wizzup> (googling around) 17:54 < Wizzup> as in, for a supl server 17:54 < bencoh> Wizzup: https://github.com/fairwaves/RRLP-2.8 17:54 < Entitlement> bencoh - [ GitHub - fairwaves/RRLP-2.8: OpenBTS 2.8 RRLP server, Fairwaves version ] 17:55 < bencoh> that's for the rrlp part 17:56 < bencoh> I don't remember whether they implemented the SUPL part, but if not, one would need to wrap the RRLP payload in SUPL packets 17:56 < tmlind> well just having a server proxying the supl data from various sources should do, sort of what ntpd does 17:57 < Wizzup> it would be nice to have a supl server one can just run, though 17:57 < tmlind> yup 17:57 < bencoh> tmlind: yup, that's exactly what we started doing on maemo5/n900 17:57 < Wizzup> all of this sounds like we will just do GPS with A-GPS first though ;) 17:57 < Wizzup> (for leste, to at least get the frameworks in place) 17:58 < bencoh> I ran a supl-proxy everytime I needed to get a gps fix 17:54 < bencoh> Wizzup: https://github.com/fairwaves/RRLP-2.8 17:54 < Entitlement> bencoh - [ GitHub - fairwaves/RRLP-2.8: OpenBTS 2.8 RRLP server, Fairwaves version ] 17:55 < bencoh> that's for the rrlp part 17:56 < bencoh> I don't remember whether they implemented the SUPL part, but if not, one would need to wrap the RRLP payload in SUPL packets 17:56 < tmlind> well just having a server proxying the supl data from various sources should do, sort of what ntpd does 17:57 < Wizzup> it would be nice to have a supl server one can just run, though 17:57 < tmlind> yup 17:57 < bencoh> tmlind: yup, that's exactly what we started doing on maemo5/n900 17:57 < Wizzup> all of this sounds like we will just do GPS with A-GPS first though ;) 17:57 < Wizzup> (for leste, to at least get the frameworks in place) 17:58 < bencoh> I ran a supl-proxy everytime I needed to get a gps fix 17:58 < Wizzup> I should probably do it on fremantle too, didn't look at the proxying 17:58 < bencoh> (I think it stopped working at some point, but I haven't investigated it. It might be a cert issue) 17:58 < tmlind> well i meant running a proxying supl server on maemo.org picking data from various sources so devices would just point to the maemo supl server 17:58 < bencoh> Wizzup: Sicelo eventually wrote a howto https://wiki.maemo.org/N900_GPS_Proxy 17:58 < Entitlement> bencoh - [ N900 GPS Proxy - maemo.org wiki ] 17:59 < bencoh> tmlind: *nod* 17:59 < Wizzup> check 17:59 < Wizzup> tmlind: ah, right 17:59 < Wizzup> that's definitely a good stopgap at least 18:00 < bencoh> We almost have the code for that 18:00 < tmlind> yeah then adding supl data from some open source data feed could be just added 18:00 < bencoh> we just need to add multi-client support to supl-proxy 18:00 < tmlind> cool 18:01 < bencoh> err, except that supl-proxy will actually fetch data for every request 18:01 < tmlind> heh that probably creates a google maps traffic jam to where that server is hosted :) 18:01 < bencoh> :)) 18:02 < tmlind> not sure if there are some legal aspects to consider there, not familiar with the supl stuff really 18:02 < bencoh> you need to supply a valid cell (mnc/lac/whatever) coordinate, and supl response is customized accordingly 18:02 < bencoh> afaict 18:02 < tmlind> huh why do you need mnc/lac? 18:03 < tmlind> to limit the data size? 18:03 < bencoh> I'm pretty certain you wouldn't need it in theory to get a full ephemeric/almanac dump 18:03 < tmlind> bbl 18:03 < bencoh> but iirc it's mandatory for supl.google.com 18:04 < bencoh> (I can see a pretty good reason for that, actually ... google loves knowing where you are) 18:06 < Wizzup> yeah 18:06 < Wizzup> from 3) A-GPS here , there seem to be only a few https://www.reddit.com/r/privacy/comments/cldrym/how_to_degoogle_lineageos_in_2019/ 18:06 < Entitlement> Wizzup - [ How to deGoogle LineageOS in 2019 : privacy ] 18:06 < Wizzup> (providers that run a supl server) 18:12 < bencoh> wow, supl.sonyericsson.com actually works as well 18:13 < bencoh> and vodafone too. funny, last time I tried I couldn't use it 18:17 < tmlind> cool, anyways multiple source for the proxying supl server would be best, sort of like with nptd 18:17 * bencoh nods