GPSd on Android

If anybody is interested in working with GPS hardware, GPSd has accepted a bunch of patches I wrote for getting it working on Android.

It includes the whole works, gpsd itself, client library, gnss hal, init scripts, selinux policy, and manifest.

Check out the master branch of gpsd into external/gpsd and follow the readme in android/

Should work with any hardware that is compatible with gpsd.

4 Likes

Hello,

I know this post it quite old but it will be very helpful if you can share the project link. I am currently working into trying to obtain gnss data from the adsp itself of the APQ8016E (db410c).
This is something I am trying to do in Android aosp. I have good most of the knowledge on the android framework, but no idea how to interface with adsp, I think I read it is done with sockets (that’a all I know).

Thanks

Nothing special. Android support is in upstream GPSd.
https://gpsd.gitlab.io/gpsd/index.html

But be aware that it does NOT include any of the parts for the qualcomm built in GPS receivers, so you’ll have to find the applicable patches and add them in order to make that work.

Or just use a USB GPS, which will have much better performance.

I see. thanks for the link.
I’ve seen this patch (that is probably made by you): Add Qualcomm PDS (!139) · Merge requests · gpsd / gpsd · GitLab

Is this something still valid? If so, is it supposed to be agnostic from the actual qcom chipset?

I checked into AOSP, I can find this:
https://android.googlesource.com/platform/hardware/qcom/gps/+/refs/heads/master

but first, it does not include msm8016e and it seems they have different implementations for different chipset…you think it is a better choice going with external receiver?

That is NOT my patch. That is from @alimon .
This link has the discussion and will give a better idea what its state is: Add Qualcomm PDS (!139) ¡ Merge requests ¡ gpsd / gpsd ¡ GitLab

My notes: fairly recent (1 month), and it looks like the “blocker” has something to do with documentation.

That AOSP link is useless. Its related to the downstream qualcomm mess of blobs and will not work with an upstream kernel.

From my point of view, yeah, if you’re working with an actual db410c rather than developing a custom board based on that SoC, don’t waste too much time trying to get the built-in GPS working. The antenna on the 410c barely works at all, even if you’re outside with a clear view of the sky all around you. Expect TTFF in the range of 30 mins best case to several hours or never. That means that you will need to modify the board to connect an external antenna. The cost of the modification, plus the cost of an external antenna will probably add up to more than the cost of a USB GPS (say a U-Blox 8, ~$15). A USB GPS will give you a good lock in seconds, and won’t need any patches to GPSd.

@denny The patch access the GPS using PDS protocol over QMI messages, If another QCOM SoC uses the same protocol could be work without modifications or small adaptations. @bamse has better details about it.

yeah, I can understand that the project is not accepting material without any doc. Shame to qcom (but honestly all of them, most of the boards are supported at 50%, anyway, not here to complain).
I also guessed that what’s included in aosp is strictly related to pixel phones and probably most blobs are custom arranged for google and without doc it’s like navigating in the dark.
I will check the proposed receiver that can be connected to the usb port, if it is supported right away with the gpsd android hal it will solve my issue. Thanks!

It would be nice to use the qcom soc for that since it will probably be a replicated demo but the lack of doc scares me a bit. If I try to apply the patch and something it is not working (most probable outcome) I have no idea how to start to debug it…thanks for the info in regards to the protocol / messages, I will try to check if something online is available in this regard.

Hi @alimon,

I’ve integrated the gpsd with your patch, I am testing using gps_test application. Here is what I get from the service:

08-05 22:26:22.668 1644 1644 D gpsd_wrapper: Starting gpsd: /vendor/bin/logwrapper /vendor/bin/gpsd -Nn -D3 pds://any
08-05 22:26:22.732 1646 1646 I gpsd : gpsd:INFO: launching (Version 3.20.1~dev)
08-05 22:26:22.733 1646 1646 I gpsd : gpsd:INFO: listening on port gpsd
08-05 22:26:22.734 1646 1646 E gpsd : gpsd:ERROR: NTP: shmget(1314148400, 96, 600) fail: Function not implemented
08-05 22:26:22.734 1646 1646 E gpsd : gpsd:ERROR: NTP: shmget(1314148401, 96, 600) fail: Function not implemented
08-05 22:26:22.734 1646 1646 E gpsd : gpsd:ERROR: NTP: shmget(1314148402, 96, 666) fail: Function not implemented
08-05 22:26:22.734 1646 1646 E gpsd : gpsd:ERROR: NTP: shmget(1314148403, 96, 666) fail: Function not implemented
08-05 22:26:22.734 1646 1646 E gpsd : gpsd:ERROR: NTP: shmget(1314148404, 96, 666) fail: Function not implemented
08-05 22:26:22.734 1646 1646 E gpsd : gpsd:ERROR: NTP: shmget(1314148405, 96, 666) fail: Function not implemented
08-05 22:26:22.735 1646 1646 E gpsd : gpsd:ERROR: NTP: shmget(1314148406, 96, 666) fail: Function not implemented
08-05 22:26:22.735 1646 1646 E gpsd : gpsd:ERROR: NTP: shmget(1314148407, 96, 666) fail: Function not implemented
08-05 22:26:22.735 1646 1646 E gpsd : gpsd:ERROR: shmget(0x47505344, 24512, 0666) for SHM export failed: Function not implemented
08-05 22:26:22.735 1646 1646 I gpsd : gpsd:INFO: stashing device pds://any at slot 0
08-05 22:26:22.735 1646 1646 I gpsd : gpsd:INFO: gpsd_activate(2): activated GPS (fd 5)
08-05 22:26:22.736 1646 1646 I gpsd : gpsd:WARN: NTP: ntpshm_alloc() failed
08-05 22:26:22.736 1646 1646 I gpsd : gpsd:INFO: PPS:pds://any ntpshm_link_activate: 0
08-05 22:26:22.736 1646 1646 I gpsd : gpsd:INFO: device pds://any activated
08-05 22:26:22.737 1646 1646 I gpsd : gpsd:INFO: running with effective group ID 0
08-05 22:26:22.737 1646 1646 I gpsd : gpsd:INFO: running with effective user ID 9999
08-05 22:26:22.738 1646 1646 I gpsd : gpsd:INFO: startup at 2020-08-05T22:26:22.000Z (1596666382)
08-05 22:26:22.738 1646 1646 E gpsd : gpsd:ERROR: QRTR connect: End of lookup, No PDS service found for pds://any.
08-05 22:26:22.738 1646 1646 I gpsd : gpsd:INFO: GPS on pds://any returned error -1 ( 0.002893437 sec since data)
08-05 22:26:22.738 1646 1646 I gpsd : gpsd:WARN: device read of pds://any returned error or packet sniffer failed sync (flags {})
08-05 22:26:22.739 1646 1646 I gpsd : gpsd:INFO: closing GPS=pds://any (5)
08-05 22:26:29.430 1646 1646 I gpsd : gpsd:CLIENT: => client(0): {“class”:“VERSION”,“release”:“3.20.1~dev”,“rev”:“3.20.1~dev”,“proto_major”:3,“proto_minor”:15}\x0d\x0a
08-05 22:26:29.431 1646 1646 I gpsd : gpsd:INFO: reconnection attempt on device 0
08-05 22:26:29.431 1646 1646 I gpsd : gpsd:INFO: gpsd_activate(2): activated GPS (fd 6)
08-05 22:26:29.431 1646 1646 E gpsd : gpsd:ERROR: QRTR connect: End of lookup, No PDS service found for pds://any.
08-05 22:26:29.432 1646 1646 I gpsd : gpsd:INFO: GPS on pds://any returned error -1 ( 0.000375521 sec since data)
08-05 22:26:29.432 1646 1646 I gpsd : gpsd:WARN: device read of pds://any returned error or packet sniffer failed sync (flags {})
08-05 22:26:29.432 1646 1646 I gpsd : gpsd:INFO: closing GPS=pds://any (6)
08-05 22:26:29.432 1646 1646 I gpsd : gpsd:CLIENT: <= client(0): ?WATCH={“enable”:true,“json”:true};\x0a
08-05 22:26:29.432 1646 1646 I gpsd : gpsd:INFO: gpsd_activate(2): activated GPS (fd 6)
08-05 22:26:29.433 1646 1646 I gpsd : gpsd:CLIENT: => client(0): {“class”:“DEVICES”,“devices”:[{“class”:“DEVICE”,“path”:“pds://any”,“driver”:“Qualcomm PDS”,“activated”:“2020-08-05T22:
26:29.433Z”}]}\x0d\x0a{“class”:“WATCH”,“enable”:true,“json”:true,“nmea”:false,“raw”:0,“scaled”:false,“timing”:false,“split24”:false,“pps”:false}\x0d\x0a
08-05 22:26:29.433 1646 1646 E gpsd : gpsd:ERROR: QRTR connect: End of lookup, No PDS service found for pds://any.
08-05 22:26:29.434 1646 1646 I gpsd : gpsd:INFO: GPS on pds://any returned error -1 ( 0.001031302 sec since data)
08-05 22:26:29.434 1646 1646 I gpsd : gpsd:WARN: device read of pds://any returned error or packet sniffer failed sync (flags {})
08-05 22:26:29.434 1646 1646 I gpsd : gpsd:CLIENT: => client(0): {“class”:“DEVICE”,“path”:“pds://any”,“activated”:0}\x0d\x0a
08-05 22:26:29.434 1646 1646 I gpsd : gpsd:INFO: closing GPS=pds://any (6)
01-01 00:13:43.238 0 0 I logd : logdr: UID=0 GID=0 PID=1649 b tail=0 logMask=99 pid=0 start=0ns deadline=0ns

I am using this kernel:
https://git.linaro.org/people/amit.pundir/linux.git
branch: db410c-android-mainline-tracking

I have compiled the kernel with db410c_defconfig but enable the QRTR driver.

Any suggestion on this?

Thanks

I think you may need this:

https://git.linaro.org/people/bjorn.andersson/qrtr.git

And then of course, you’ll need to start it with something like qrtr-cfg 1 && qrtr-ns

And of course, that has to happen before you start gpsd.

And note that I don’t know the meaning of the parameter. 1 might not be the right argument.

thanks for the tip. I had actually integrated that service, from another repo that seems to be more updated: https://github.com/andersson/qrtr. Same guy, just on github.
I’ve spent some time in debugging today, here is what I found:

  1. the qrtr service seems to discover services, it is able to find two services, service 15 and 256
  2. gpsd service when starting it is querying qrtr and checking for a service with id 16 (0x10) and it is using PDS version 2
  3. the requested arrives at qrtr but the service id it does not exist and it exit. Moreover, if I check the service 15, it has PDS version equal to 0

Now, I don’t have idea on how the service is discovered or why only the two services are there. Not sure if depends on the image flashed into adsp or it is related to the qrtr driver version that is not matching with the service. Any help will be much appreciated.

This is the piece of code that return because service id is not found. ns.c in the qrtr prohect.

static int server_match(const struct server *srv, const struct server_filter *f)
{
unsigned int ifilter = f->ifilter;

    // f->service is the one asked from driver_pds.c of gpsd QMI_PDS_SERVICE_ID
    // srv->service is the service supported, first 15 than 254
if (f->service != 0 && srv->service != f->service)
	return 0;

    // ifilter is equal to 0
    // f->instance is coming from driver_pds.c it's equal to 2: QMI_PDS_VERSION
    // BTW, this code is never executed
if (!ifilter && f->instance)
	ifilter = ~0;

return (srv->instance & ifilter) == f->instance;

}

As always, thanks

@denny, this thread is about hikey960 maybe you should create an other one for your case and specify which board and release you’re running.

The GPS is exposed via a service available via the QCOM IPC-router driver (which in turn relies on IPCRTR smd edge).

On debian/410c, you can get available services with

qrtr-lookup 
Service Version Instance Node  Port
  256       0        1    0     1 <unknown>
   43       1        0    0     2 Subsystem control service
   15       1        0    0     8 Test service
   51       1        2    0     9 CoreSight remote tracing service
   24       1        0    0    10 Thermal mitigation device service
   23       1        0    0    11 Thermal sensors service
   22       1        1    0    12 Time service
   34       1        0    0    13 Coexistence service
   16       2        0    0    14 Location service (~ PDS v2)
   14       1        0    1    14 Remote file system service
  256       0        1    7     1 <unknown>
   15       1        0    7     2 Test service

If the locastion service does not appear in your case, check that the firmware (qcom/msm8916/mba.mbn) is aligned with the latest release.

Hi @Loic,

yes you are right, sorry about that, I started posting here just because I saw message from doitright talking about gnss.
Thanks for the explanation, it makes things a little more clear.
The reason why it is not working than it’s clear! I do not have that mba.mbn. I am building the android AOSP directly from android code base.

I cannot find the mba.mbn file even inside here:
http://builds.96boards.org/releases/dragonboard410c/qualcomm/firmware/linux-board-support-package-r1032.1.zip

Do you know if it has a different name or where I can find it?

@update:
if the blobs are inside fs_image_linux.tar.gz.mbn.img it’s where I have the problem. While flashing the fsg partition, I receive this message:

Sending ‘fsg’ (2048 KB) OKAY [ 0.068s]
Writing ‘fsg’ FAILED (remote: ‘size too large’)
fastboot: error: Command failed

Thanks!