Controlling the GPS chip (Qualcomm WGR7640)


#1

I’ve installed the following bootloader, kernel, and rootfs:

  • dragonboard410c_bootloader_emmc_linux-72.zip
  • linaro-jessie-developer-qcom-snapdragon-arm64-20161006-144.img.gz
  • boot-linaro-jessie-qcom-snapdragon-arm64-20161006-144.img.gz

I’ve also installed the following packages:
gpsd-clients gnss-gpsd

I’ve also started the DSP:
sudo systemctl start qdsp-start.service

After this, I am able to use xgps to monitor the GPS status.
However, I am looking for ways to control the GPS beyond the default configuration that is applied.

I’ve also briefly looked at the IPC driver here:
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/tree/net/qrtr

I am still looking for the userspace code that uses this driver
I’m guessing its the source for this package: gnss-gpsd <- I cannot seem to locate this

If I understand correctly userspace and GPS communication works like so:
[xgps] <—> [gnss-gpsd] <—> [qrtr] <-IPC-> [dsp code] <-SSBI-> [WGR7640]

Also, I’ve identified this manual:

The doc makes reference to ‘singlewire serial bus interface (SSBI) for efficient initialization, status, and control’. However, it doesn’t go into further detail on how this communication works (I’m assuming it’s proprietary and currently done using the DSP)

Is there any documentation, DSP code, kernel or userspace code, that may give better insight into how the GPS is currently configured and what additional configuration may be available?
Ultimately, I would like to turn off the WGR7640 chip completely or turn off as much of the internal circuitry as possible.

I appreciate all the hard work that has been done thus far from the 96 boards and the community as a whole. Also, thanks in advance for reviewing this.


#2

Hi @wcampbell

The WGR7640 is nothing more than an RF front end for the GPS. The WGR contains a basic RF filter, a local VCO oscillator, and a down-mixer. The output of the WGR7640 is a analog baseband signal which is sent to the APQ8016. The APQ8016 contains the Analog to Digital converters, and all of the signal processing for extracting the GPS signals.

The SSBI data line only does simple things like adjusting the local oscillator frequency, and other minor adjustments to the analog front end. There is no ‘GPS’ data on the SSBI interface. All of the signal extraction, and intelligence is in the APQ8016.

Under the Android operating system if the GPS is not in use, the WGR7640 is automatically powered down, additionally all of the GPS circuitry internal to the APQ8016 is also powered down. If the GPS icon is not displayed on the status bar, it is all fully powered down. It is a slightly different story under Debian, not all of the power saving features available to the APQ8016 are fully implemented at this time, however if you do not activate the GPS it will not be powered up.

Full Disclosure: I am an employee of Qualcomm Canada, and opinions I may have expressed in this or any other post may not reflect the opinions of my employer.


#3

Thanks Lawrence for bumping this topic, I had missed it.

In the current model “[gnss-gpsd]” involves a few more pieces, but your understanding is correct.

The “[dsp code]” implements the “Position Determination Service (PDS)” protocol, which is a set of QMI encoded messages for configuring the GPS and receive notifications. The current implementation enables NMEA reporting and provides the responses to gpsd, but in addition to this there are useful commands for e.g. injecting known position to speed up the finding of a fix. We use qrtr for the transport of these messages.

Afaict the PDS protocol documentation is not public, but it’s converted to C-code as part of the open source loc_api at [1].

[1] https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/location/tree/loc_api/loc_api_v02

Regards,
Bjorn