Difference between revisions of "Status/GPS"
From Maemo Leste Wiki
Jump to navigationJump to search| Line 11: | Line 11: | ||
* https://github.com/maemo-leste/bugtracker/issues/57 | * https://github.com/maemo-leste/bugtracker/issues/57 | ||
* http://talk.maemo.org/showthread.php?t=100363 | * http://talk.maemo.org/showthread.php?t=100363 | ||
* (On combining multiple gps sources such as A- | * <s>(On combining multiple gps sources such as A-GPS/SUPL and gpsd) https://lists.gnu.org/archive/html/gpsd-dev/2012-07/msg00018.html</s> (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 | * supl implementation: https://github.com/tajuma/supl | ||
* https://talk.maemo.org/showthread.php?t=93910 | * https://talk.maemo.org/showthread.php?t=93910 | ||
Revision as of 20:42, 29 June 2020
Fremantle Gypsy
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.
Relevant URLs
- https://github.com/maemo-leste/bugtracker/issues/151
- https://github.com/maemo-leste/bugtracker/issues/57
- http://talk.maemo.org/showthread.php?t=100363
(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
- https://talk.maemo.org/showthread.php?t=93910
- https://github.com/postmarketOS/gps-nokia-n900/blob/master/gps-nokia-n900.c
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 [~peetah@cha92-9-82-236-202-86.fbx.proxad.net] 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
