Determining your physical location in Mobian is a fairly complex topic. There are a number of layers involved. Digging into the details takes some effort. Hopefully, this page will help you to dive in and see what is going on.

Warning: a lot of people are reporting that the GPS has poor sensitivity, see https://forum.pine64.org/showthread.php?tid=11680

Warning: The ModemManager GPS functionality works only when an active SIM is present. (However it does not require SIM credit or a dataplan. And if you don't have a SIM card, then you can still access the GPS from the modem via gpsd)

TL;DR When the Mobian first time setup wizard asks if you want to send location data to Mozilla Location Services answer “Yes.” Use either Maps or install PureMaps. Run one of those apps in the background (or foreground) when you're traveling around with WiFi and Mobile Data enabled. For vehicle navigation, position your phone to have a good view of the sky when inside, and keep it in the open every once in a while for at least a few minutes so that it can find the satellites.

Source Data

Many people consider it to be the role of GPS (Global Positioning System) to provide their phone with their physical location. In reality there are a number of different sources that go into fixing your location, each with their own tradeoff in terms of reliability, speed, and accuracy.


The Global Navigation Satellite System consists of a number of different positioning satellite constellations. The United State's GPS is the oldest and most famous, but there are others such as Galileo from the EU, GLONASS from Russia and Beidou from China. All of these constellations are supported by the EG25 modem in the PinePhone and are almost entirely transparent to the user.

Determining one's position using GNSS is done through a process of triangulation based on positional information about the satellites in orbit continually broadcast from space and the messages from each satellite with a very precise time. The differences between the times broadcast by different satellites and the “almanac” of satellite positions allows it to calculate your current position: latitude, longitude, altitude and a number of metrics indicating the precision of those measurements. The precision increases given the number of satellites that are detected and also other information such as bearing and speed.

Luckily, there is a standard for GNSS location and status information called NMEA (National Marine Electronics Association), which is available in most navigation equipment. In Mobian, this information can be seen directly using the mmcli (ModemManager CLI).

$ sudo mmcli -m any --location-enable-gps-nmea --location-enable-gps-raw
successfully setup location gathering
$ sudo mmcli -m any --location-get
... Sometimes there is additional 3GPP (cell phone) location data here ...
  GPS  |               nmea: $GPGSA,A,3,13,15,20,21,,,,,,,,,2.8,2.6,1.0,1*19
       |                     $GPRMC,215904.00,A,2518.123453,N,072.1111,W,0.0,21.7,310720,10.8,W,A,V*41
       |                     $GPGSV,3,1,12,05,20,084,22,10,06,272,21,13,51,059,32,15,81,123,34,1*6C
       |                     $GPVTG,21.7,T,32.5,M,0.0,N,0.0,K,A*23
       |                     $GPGGA,215904.00,2518.123453,N,07211.11111,W,1,04,21.1,114.4,M,-36.0,M,,*64
       |                utc: 215904.00
       |          longitude: -72.11111
       |           latitude: 25.123453
       |           altitude: 114.400000

The first time you try this, it might take a very long time to get an initial fix. Also, you'll need to give the phone a very clear view of the sky, outside of a building and clear of tall buildings. This will help ensure that it is able to locate the satellites in view and download the almanac of satellite positions. Subsequent fixes seem to be easier to achieve after there is an up-to-date almanac.

When testing the modem wtih CLI it is convenient to use the watch command to repeatedly query the current position. The -n option defines the interval in seconds, five seconds for example:

watch -n 5 mmcli -m any --location-get

When gps-nmea location is enabled in mmcli it will give you a number of NMEA fields like above can be decoded. Check out this reference guide for more information about each field. http://www.gpsinformation.org/dale/nmea.htm From this guide you will be able to see that this fix came from reading 12 satellites and overall, vertical and horizontal Dillution of Precision 2.8, 2.6 and 1.0, which is actually very good. There is alot of other data embedded there like your current bearing and speed, but that's left as an exercise to the reader to interpret those. The information about your location fix will be in the $GPGGA field or just a bunch of commas ',,,,,,' if a location cannot be determined at that point.

With GNSS it is possible to get your precise position within centimeters without the help of any other external source if the conditions are right. If you are trying to get your position “cold” it can take some time to wait for the almanac information about the satellite locations. Also, it can take more time to identify enough satellite signals to get a fix. It can take even more time to get a very precise fix. If there are any obstructions, such as buildings or tunnels or even bad weather this an take longer and become less reliable, especially on a mobile phone. This is why systems such as Mobian don't rely on a single input to pinpoint your location.

Quectel EC2SEC21 vendor documentation: https://sixfab.com/wp-content/uploads/2018/09/Quectel_EC25EC21_GNSS_AT_Commands_Manual_V1.1.pdf

Speeding up GPS fix with AGPS

As noted above, the initial GPS fix can be slow and unreliable. Downloading assistance data from the internet and sending it to the modem makes this a lot faster and more reliable. Smartphones tend to do this automatically, leading to an expectation of this level of performance. This isn't yet (20201002) the case for Mobian. There's a proof-of-concept script(error 404) you can try, but proper support requires a fix to ModemManager for its upload method to work with the Quectel modem.

Why the slow fix?

When doing a 'cold start' the GPS receiver first needs to collect enough data from the satellites' signal to work out what the GPS time is and where the satellites are. See this primer for details. The biggest data block is the almanac, and because of the low data rate it takes 12.5 minutes to send completely.

Modern smartphones don't have enough room for a good GPS antenna, and contain many potential sources of interference, so the signal to noise ratio is rather low. This makes it more likely that there will be errors or gaps in the reception of the initial data, and it won't come around again for 12.5 minutes. If you're lucky you'll get the satellites in an advantageous position, and collect enough data to get you going within a few minutes. If you're unlucky you could be waiting a _lot_ longer!

AGPS cuts all this out by downloading the almanac and ephemeris data from a web server, and setting the time from a network time server. This gives the receiver the complete set of information almost instantly, allowing a much faster and more reliable position fix. The down side is that it only works when you have a network connection, and you're making a request to a web server which some might consider a potential privacy issue.

Radio Stations

No, this is not the typical radio stations that broadcast the news or music. These are stations that generally don't move around too much, such as cellphone towers, WiFi hotspots and even bluetooth low energy beacons. If you are receiving a signal from one of these stations then you are likely to be in a specific spot on the planet within a few kilometers with cellphone towers or 100's of meters of a WiFi hotspot or bluetooth beacon.

You can use the ModemManager to see the information about your current cellular phone (3gpp) connection information. This information uniquely identifies the single cell phone tower that you are currently connected.

$ mmcli -m any --location-get
  3GPP |      operator code: 302
       |      operator name: 110
       | location area code: 0000
       | tracking area code: DAE2
       |            cell id: 086C5B39
... Potentially some GNSS NMEA Information ...

If you access mmcli directly from your phone, you don't need sudo rights, but if you access mmcli via ssh then you need sudo mmcli. Otherwise you run into something like:

error: couldn't get location from the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unauthorized: PolicyKit authorization failed: not authorized for 'org.freedesktop.ModemManager1.Location''

Also, you can use the NetworkManager to query for WiFi networks currently around you.

$ sudo iwlist scan
wlan0     Scan completed :
          Cell 01 - Address: 90:72:82:F2:89:36
                    Protocol:IEEE 802.11bgn
                    Frequency:2.412 GHz (Channel 1)
                    Encryption key:on
                    Bit Rates:300 Mb/s
                    Quality=96/100  Signal level=-78 dBm  
           Cell 02 -

Unfortunately, none of these radio stations broadcast their specific locations on the Earth. There needs to be a database somewhere that keeps track of them and correlated their presence with rough location. Such databases already exist, some private like the ones used in Android and iOS. There's an open source (the code is available), but closed data (no data dumps of the database) one called Mozilla Location Service (MLS). The implementation and REST API is called Ichnaea. This service is the one available to Linux (Mobian) users. It goes without saying that any of these databases requires an active internet connection through WiFi or cellular data.

IP Address

As long as you have an Internet connection, you also have some sort of public IP address where your outgoing traffic goes. IP addresses can be associated with a rough geographic region, such as a city or region of a country. Note that a mobile IP (i.e. the only IP address is from your mobile carrier) location can vary widely (this author has anecdotally seen it off by 1000km). IP addresses also don't have an intrinsic geolocation, so this also requires some kind of database that will return a rough location from the address.

The Mozilla MLS service also provides an IP Address geolocation as an automatic fallback to their geolocation service. If their database doesn't know about the nearby radio stations or if your phone is unable to find any then it will use your outgoing request to their service to find your public IP Address and use a third-party provider. GeoIP locations are pretty bad and so this is definitely a fallback to use if no other source of location data can be found. But at least the lookup is very fast. This will need an active internet connection to work.

Setup gpsd

The gpsd service directly interacts with the modem, bypassing ModemManager. It doesn't ship with mobian and needs to setup before usage. First install gpsd and its utilities:

sudo apt install gpsd gpsd-clients
scale-to-fit xgps on
scale-to-fit xgpsspeed on

Open /etc/default/gpsd and add the EG25 modem to the device list:


Start the gpsd service and check its status:

sudo systemctl start gpsd.service
sudo systemctl status gpsd.service

Access the NMEA formatted GPS information directly from your EG25 modem:

gpspipe --nmea

Once you got a GPS fix, the output should look like. You can speed up the process of getting a GPS fix as explained above, with the experimental load_agps_data.py script:


XXX and YYY is your exact latitude and longitude, respectively. Once, you got that GPS fix, start xgps app in Phosh, as it will give you a much better overview, of how many and which satellites are currently used.

Software Stack

Now that you have a sense of the different types of location sources with their advantages and disadvantages let's look at the Mobian software stack to support these different capabilities and services. You've already seen ModemManager (mmcli) above. It is responsible for all modem interactions in areas such as GNSS and 3GPP if they are available. There is also the NetworkManager and wireless tools (iwlist) that are responsible for managing your current internet connection and detecting details of nearby WiFi endpoints.

If you are lucky enough to get a GNSS fix using the ModemManager at the point where you need a location then that's great. However, none of these tools can gather together all the pieces of information to get you the best possible location from the MLS geolocation database when that isn't available. This is where GeoClue comes into play. It is the piece that is capable of using all of these sources of information and providing a user application with your location and accuracy. In fact, this is the service that Maps uses to show you your current location. You were probably wondering why the location bounces around on there sometimes. Now you know. The same is true for the PureMaps turn-by-turn navigation application.

If you have a favourite website that you would like to use with location information the GNOME Web browser will integrate with GeoClue if you give it permission to do so. Note that a number of websites such as Google Maps and OpenStreetMap do not request high accuracy in the HTML5 GeoLocation API, which limits the accuracy that GeoClue will provide and it usually falls back to IP Geolocation with its terrible accuracy, although this might be improved in a new webkit release. These and other websites can request high accuracy and GeoClue will provide GNSS position when possible.

Building location aware applications

Using GeoClue, one can take advantage of the best available location information. Here's a short tutorial to build a location-aware application.


Detailed GeoClue Logging

Now that you have an understanding of the sources of data for your location and how GeoClue can derive the best possible location from those sources at a given time, let's see it in action. One way to do this is to enable debug logging for the service. This will allow you to watch directly while you move around or query it for specific trips that you've made with your phone.

Change your /usr/lib/systemd/system/geoclue.service to add a special environment variable in the “[Service]” section.


Reload the geoclue systemd unit:

$ sudo systemctl daemon-reload

Restart the geoclue service:

$ sudo systemctl restart geoclue.service

Now you can look at the latest events (20) in geoclue with journalctl:

$ sudo journalctl -u geoclue.service -n 20

You can look back at the logs at a certain point in time like this:

$ sudo journalctl -u geoclue.service -S "2020-07-31 18:17:00"

Here's an example set of log entries. In this log you can see that some WiFi access points where discovered and added to the current set. The MLS geolocation service was successfully invoked and gave back a (very inaccurate) location. At 25km this was probably a fallback to an IP Address lookup because the WiFi AP's weren't known to MLS (see the fallback is “ipf”). Later on the WiFi AP's were no longer detected possibly because of movement that left them out of range.

Jul 20 11:20:19 pinephone geoclue[2007]: WiFi AP 'xyz1' added.
Jul 20 11:20:19 pinephone geoclue[2007]: WiFi AP 'xyz2' added.
Jul 20 11:20:19 pinephone geoclue[2007]: WiFi AP 'xyz3' added.
Jul 20 11:20:19 pinephone geoclue[2007]: WiFi AP 'abc1' added.
Jul 20 11:20:19 pinephone geoclue[2007]: WiFi AP 'abc2' added.
Jul 20 11:20:20 pinephone geoclue[2007]: Got following response from 'https://location.services.mozilla.
                                               {"location": {"lat": 25.1234, "lng": -78.5678}, "accuracy": 25000.0, "fallback": "ipf"}
Jul 20 11:20:20 pinephone geoclue[2007]: location scrambled
Jul 20 11:20:20 pinephone geoclue[2007]: GClueWifi got new heading 0.000000
Jul 20 11:20:20 pinephone geoclue[2007]: New location available
Jul 20 11:20:20 pinephone geoclue[2007]: Time difference between previous and new location is 302 second
s and below threshold of 3600 seconds.
Jul 20 11:20:20 pinephone geoclue[2007]: Updating location, below threshold
Jul 20 11:24:33 pinephone geoclue[2007]: WiFi AP 'xyz1' removed.
Jul 20 11:24:33 pinephone geoclue[2007]: WiFi AP 'xyz2' removed.
Jul 20 11:24:33 pinephone geoclue[2007]: WiFi AP 'abc1' removed.

Here is another trace. This time a cell phone tower was used successfully to get a somewhat accurate (1km) location. The NMEA ($GP)GGA trace was empty so the GNSS could not get a fix at this point. This is why the MLS service was contacted with the cell phone tower information.

Jul 30 17:16:00 pinephone geoclue[2072]: Sending following request to 'https://location.services.mozilla.com/v1/geolocate?key=geoclue':
Jul 30 17:16:00 pinephone geoclue[2072]: New GGA trace is same as last one: $GPGGA,,,,,
Jul 30 17:16:00 pinephone geoclue[2072]: WiFi scan timeout. Restarting-scan..
Jul 30 17:16:02 pinephone geoclue[2072]: Got following response from 'https://location.services.mozilla.com/v1/geolocate?key=geoclue':
                                               {"location": {"lat": 24.300082, "lng": -76.183612}, "accuracy": 1000.0}
Jul 30 17:16:02 pinephone geoclue[2072]: GClue3G got new heading 0.000000

In this example there are WiFi access points detected nearby, but still no GNSS fix. WiFi access points can sometimes offer better accuracy than cell phone towers with MLS because the range is much smaller.

Jul 30 17:18:54 pinephone geoclue[2072]: Sending following request to 'https://location.services.mozilla.com/v1/geolocate?key=geoclue':

Submitting Location Data to MLS

As you can see location is fairly often determined using the Mozilla Location Services, whether it uses cell towers or WiFi access points. If the data isn't there in its database to determine your location based on the available information then you are left with only the IP Address, which provides terrible accuracy. Fortunately, with your shiny new PinePhone (or even an Android App) there are ways you can help keep the database up to date.

GeoClue has a built-in feature where it can actually publish radio station information (cell tower, wifi, bluetooth beacons) along with your current GNSS fix. Enabling it is pretty easy. Edit your /etc/geoclue/geoclue-conf and change the value of “submit-data” to true. There is a rumour that the Mobian initial setup wizard will also set this for you if you answer the question the right way.

# Submit data to Mozilla Location Service
# If set to true, geoclue will automatically submit network data to Mozilla
# each time it gets a GPS lock.

Once you change this value you can either reboot your phone or restart the geoclue service (sudo systemctl restart geoclue.service). If you happen to have your GeoClue tracing turned on you can see if/when it posts information to MLS. In this case it was a nearby WiFi access point that it discovered at the same time as a GNSS fix.

Jul 30 18:24:03 pinephone geoclue[2072]: Sending following request to 'https://location.services.mozilla.com/v1/submit?key=geoclue':
Jul 30 18:24:04 pinephone geoclue[2072]: Successfully submitted location data to 'https://location.services.mozilla.com/v1/submit?key=geoclue'

Here is a version that published the presence of a cell phone (3GPP) tower.

Jul 30 18:23:03 pinephone geoclue[2072]: Sending following request to 'https://location.services.mozilla.com/v1/submit?key=geoclue':

GPS location in Aeroplane mode

In areas without network connection or WiFi networks around, which is quite common outside densely populated areas, but also during all sorts of outdoor activities, your EG25 modem is still able to determine your GPS location. Unfortunately, there is a bug in ModemManager which prevents access to raw GPS without an active SIM card.

At the moment there are workarounds for this:

gpsd based applications

As already demonstrated above, after successful setup of gpsd, your GPS location can be determined bypassing ModemManager. In order to speed your process, external loading of AGPS data, as long as you've WiFi connection is preferable:

## this only disables the EG25 modem, not the WiFi:
sudo systemctl disable ModemManager.service
sudo systemctl stop ModemManager.service
## update AGPS data on the EG25 modem
python3 /home/mobian/load_agps_data.py
## GPS fix should be there within seconds, if phone is placed properly outdoors
gpspipe --nmea

After receiving a GPS fix, you can use e.g. FoxtrotGPS for your GPS location and tracking, which directly relies on gpsd.

The location had to be activated either with ModemManager before you go into Airplane mode:

mmcli -m any --location-enable-gps-nmea --location-enable-gps-raw

or afterwards directly via AT command

sudo sh -c 'echo -ne "AT+QGPS=1\r" > /dev/ttyUSB2'

, otherwise gpsd might fail and can't produce any output from the modem.

Network NMEA

Unfortunately, GeoClue doesn't support gpsd out of the box. There seems some reasons for this. Instead GeoClue has network NMEA support. In order to get that working you need gps-share, which is actually not yet packaged for debian.

Here are instructions to compile it from source:

sudo apt install cargo libudev-dev
git clone https://github.com/zeenix/gps-share.git
cd gps-share/
cargo build --release

Make sure the build process was completed without problems. As GeoClue complained it can't find mobian.local (is there any config for GeoClue to look directly at localhost?) add the following line to /etc/hosts:       mobian.local

If you just got an AGPS fix with gpsd, all you need is to start gps-share. Make sure gpsd is not running at the same time:

sudo systemctl stop gpsd.service
## Just to make sure GeoClue is running, typical it's invoked automatically
sudo systemctl start geoclue.service
## start gps-share and talk directly to the EG25 modem
./target/release/gps-share /dev/ttyUSB1

The output should look similar to:

TCP server bound on all interfaces
Port: 10110
group: /Client9/EntryGroup1
Connection from
Connection from

The output of sudo journalctl -u geoclue.service -n 40 should read, after a GPS fix was received, like this:

Jul 05 15:18:27 mobian geoclue[13077]: GClueNMEASource got new heading 0.000000
Jul 05 15:18:27 mobian geoclue[13077]: New location available
Jul 05 15:18:27 mobian geoclue[13077]: [97B blob data]
Jul 05 15:18:27 mobian geoclue[13077]: Ignoring non-GGA sentence from NMEA source
Jul 05 15:18:27 mobian geoclue[13077]: [61B blob data]
Jul 05 15:18:27 mobian geoclue[13077]: Ignoring non-GGA sentence from NMEA source
Jul 05 15:18:27 mobian geoclue[13077]: [101B blob data]
Jul 05 15:18:27 mobian geoclue[13077]: Ignoring non-GGA sentence from NMEA source
Jul 05 15:18:27 mobian geoclue[13077]: [75B blob data]
Jul 05 15:18:27 mobian geoclue[13077]: Ignoring non-GGA sentence from NMEA source
Jul 05 15:18:27 mobian geoclue[13077]: [75B blob data]
Jul 05 15:18:27 mobian geoclue[13077]: Ignoring non-GGA sentence from NMEA source
Jul 05 15:18:27 mobian geoclue[13077]: [65B blob data]
Jul 05 15:18:27 mobian geoclue[13077]: Ignoring non-GGA sentence from NMEA source

Now open PureMaps and in combination with the offline maps from OSM ScoutServer you're able to navigate in Airplane mode!

GPS tracking when phone is suspended

Even GPS is working in Aeroplane mode, it will stop as soon as the phone is getting suspended in order to save battery. If the tracking is done in foreground directly on the phone, it can be expected that the battery will run flat after 3-5 hours.

As the modem is always supplied from the battery, one can track the GPS signal directly on the modem, even if the phone is sent into suspend mode. Therefore create a (proof of concept) script in your ($HOME) directory. The log file is stored in the /persist directory. Therefore persistent logging must be activated:


while true; do
    head -n 20 /dev/smd7 | grep -m 1 GGA >> /persist/gps.log
    sleep 60

You also need to create an init script:

#! /bin/sh
# Init script for: gps logger

set -e

case "$1" in
        echo "Starting $DAEMON" > /dev/kmsg
        start-stop-daemon -c $USER:$GROUP -S -b -a $DAEMON_PATH$DAEMON
        echo "Stopping $DAEMON" > /dev/kmsg
        start-stop-daemon -K -n $DAEMON
        $0 stop
        $0 start
        echo "Usage $0 { start | stop | restart}" >&2
        exit 1

exit 0

As the main filesystem on the modem is read-only, you need to make it writeable once to push the scripts onto the modem. You need to do this sequence again after every modem firmware update:

adb shell
sh-5.1# mount -o remount,rw /
sh-5.1# exit
adb push gps-logger.sh /usr/bin/
adb push init_gpslogging /etc/init.d/
adb shell
sh-5.1# chmod 755 /usr/bin/gps-logger.sh
sh-5.1# chmod 755 /etc/init.d/init_gpslogging

If you've problems accessing with adb, try to restart the adb server:

sudo adb kill-server
sudo adb start-server

Check with atinout if GPS had already been activated (this works even when ttyUSB2 is already locked with ModemManager):

echo 'AT+QGPS?' | sudo atinout - /dev/ttyUSB2 -

A non-complete list of AT commands can be found here.

Then you can start the gps logging remotely via adb:

adb shell "service init_gpslogging start"

You can check via adb, if the gps logging is still running, even after you've logged out from the modem, and pull the gps.log at anytime from the modem:

adb shell "ps | grep gps"
adb pull /persist/gps.log
tail gps.log

WARNING!!! These scripts do NOT reset the log file. Make sure you manually delete it in certain intervals. This was done in case the phone or modem crashes during a trip, and you need/want to continue gps logging immediately without dealing with the log files.

If you get the error message:

adb: error: failed to get feature set: device offline

You can manually activate ADB again with

echo 'AT+ADBON' | sudo atinout - /dev/ttyUSB2 -

and then check with, if the modem is online again:

adb devices

The output should look like

List of devices attached
community_fw    device

Convert log to gpx file

In order to convert the gps.log file into a gpx file to further processed by other software, you can use this simple python script. It converts the decimal minutes into decimal degrees for the gpx file. It looks for the file gps.log in the current directory, and write a gpx file in the same directory:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from datetime import datetime
import math

logfile = open("gps.log", "r")
loglist = logfile.readlines()

today = datetime.utcnow().strftime('%Y-%m-%d')
outputFile = open("gps_log_"+today+".gpx", "w")

header = """<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.0" creator="Pinephone"
 xmlns="http://www.topografix.com/GPX/1/0" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd">


footer = """\t\t</trkseg>


for i in range(len(loglist)):
    myLine = loglist[i].split(",")
    if len(myLine[2]) > 0:
        time = today+"T"+(myLine[1])[0:2]+":"+(myLine[1])[2:4]+":"+(myLine[1])[4:]+"Z"
        lat_f, lat_w = math.modf(float(myLine[2])/100)
        lat = lat_w + lat_f/.6
        lon_f, lon_w = math.modf(float(myLine[4])/100)
        lon = lon_w + lon_f/.6
        if myLine[3] == "S":
            lat = -lat
        if myLine[5] == "W":
            lon = -lon
        outputFile.write('\t\t\t<trkpt lat="'+str(lat)+'" lon="'+str(lon)+'">\n')



In Car Setup

If you are using your phone to track your vehicle movements you'll need to mount it where it can get a good view of the sky.


  1. TBD: Determine how well the modemmanager's “–location-enable-agps-ms[a|b]” works and exactly how it works on the PinePhone. Also, how it might impact GeoClue, if anything.
  2. TBD: Determine how to get this data loaded into the modem to improve GPS fix times: https://gitlab.com/Djhg2000/mobian-recipes/-/issues/5 (Note: the file comes from a link on page 27 of Quectel_EC25EC21_GNSS_AT_Commands_Manual_V1.1.pdf, but the manual doesn't come from official sources and the file URL looks fishy, so either completely reverse engineer the file to determine it is safe or source it from an official place.