Quectel in the documentation for other Qualcomm-based modem explains
in details DPO (Dynamic Power Optimization), that is enabled on EG25-G
currently. One of requirements for DPO is, that XTRA almanac must be
less that 3.5 days old. [1]
Additionally SIMCOM says, that information predicted by XTRA is very
accurate within 24 hours, but its effectiveness decreases over time. [2]
Xtra3 files are available for 1 day (xtra3grc_24h.bin), 3
days (xtra3grc_72h.bin) and 7 days (xtra3grc.bin). Currently 7 days
variant is used.
Based on recommendations from Quectel and SIMCOM to slightly improve
GNSS performance switch default configuration to 24h XTRA variant.
1. https://sixfab.com/wp-content/uploads/2018/09/Quectel_UC20_GNSS_AT_Commands_Manual_V1.1.pdf
2. https://cdn.geekfactory.mx/sim7000g/SIM7000%20Series_GNSS_Application%20Note_V1.03.pdf
SUPL (Secure User-Plane Location) is protocol for A-GPS to receive
assistance data over Internet.
EG25-G has integrated SUPL client, that uses mobile data to
communicate with SUPL server and feed assisted data into GNSS
receiver. SUPL drastically improves TTFF (time to first fix) and is
much more effective than XTRA. To configure it user has to set SUPL
version (latest supported version is 2.0), select whether or not use
SSL, set address for SUPL server.
There are more tuning options in Quectel's documentation, but default
values are good to make SUPL work:
- AT+QGPSCFG="agpsposmode" Configure AGPS Positioning Mode
- AT+QGPSCFG="lbsapn" Configure AGNSS Positioning AP
- AT+QGPSCFG="agnssprotocol" Configure AGNSS Positioning Protocols
There are some usage aspects of SUPL to be aware of:
* modem uses mobile data to get information from SUPL server
* mobile data is used even if it's disabled in operating system
* firmware seems to try TLS 1.1, that is deprecated and not used in
production anymore. See [1].
* IMSI (International Mobile Subscriber Identity) of your SIM-card,
current cell Id and public IP are leaked to SUPL server.
It's recommended to setup proxy server to hide IMSI and IP from
SUPL server [2].
* all this information is visible in trafic dumps for network nodes
in between since there is no SSL
* SUPL requests with this information are not sent constantly, when
geolocation is enabled. They are sent, when information in GNSS
receiver is outdated.
SUPL servers that could be found on the Internet:
- supl.google.com (widely used, supports SSL and non-SSL)
- supl.grapheneos.org (supports only SSL, AFAIK just proxy to supl.google.com)
- supl.vodafone.com (resolves to supl.google.com)
- supl.qxwz.com (probably doesn't provide data outside of China, Chinese company)
- supl.nokia.com (is shutdown down)
The only working SUPL server is supl.google.com.
Support in ModemManager and Geoclue is already in
place. ModemManager shows agps-msb capability and Geoclue enables
agps-msb, when it's available. When precise geolocation is requested
and assisted information is missing in the modem (cold start), when
modem requests SUPL server for new assisted data.
SUPL was successfully tested with stock modem firmware 30.007.30.007
and community firmware v0.7.4.
For testing it was often needed to delete assistance data and enforce
cold start. Following script was used for this, it requires
ModemManager run in debug mode (--debug).
```
sudo mmcli -m any --command="AT+QGPSEND"
sleep 1
sudo mmcli -m any --command="AT+QGPSDEL=0"
sleep 1
sudo mmcli -m any --command="AT+QGPSDEL=3"
sleep 1
sudo mmcli -m any --command="AT+QGPSDEL=1"
sleep 1
sudo mmcli -m any --command="AT+QGPSDEL=0"
sleep 1
```
1. https://forums.quectel.com/t/a-gnss-msb-with-tls-on-eg25-g/39334
2. https://github.com/Eierkopp/supl-proxy
Tracking more GNSS constellations increases position availability,
especially when sky view is limited or small antennas are used.
BeiDou has global availability, modem does support A-GPS data for
BeiDou. When BeiDou is enabled, its satellites are used in fix
according to PQGSA messages in NMEA stream.
Galileo constellation is kept disabled, since modem doesn't support
assistance data for Galileo. When enabled, Galileo satellites usually
don't participate in the fix.
xtra2.bin contains assistance data only for GPS and GLONASS.
xtra3grc.bin – XTRA 3.0 files, providing GPS, GLO, and BDS assistance
data (protected by a digital signature). Switching to XTRA 3.0 files
is recommended to close CVE-2016-5341.
Similar to the formatting check job, take advantage of the `clang-tidy`
configuration we just created to add a new job running this tool.
Running `clang-tidy` requires the following:
* build dependencies must be present on the system so it can resolve the
includes
* the build folder must be configured as it relies on the
`compile_commands.json` to get build flags (such as the include paths)
This could be run in the `build` job, but it would make it harder to
understand the actual underlying issue, so this is executed as a new,
separate job, re-using the artifacts from the `build` job.
This will allow us to run a static analysis tool, catching the most
obvious issues (use-after-free, potential NULL dereference...) and
(hopefully) increasing this software's overall robustness.
The current pipeline (from Mobian) just doesn't work, we should get to
a more efficient, simpler one.
With the `clang-format` config now in place, this pipeline has 2 jobs:
* ensure the code is properly formatted
* run a test build to make sure it won't break
The PinePhone has circuitry that makes this pin active-high, but the
PinePhone Pro doesn't appear to, which means we would need read active
high / active low from the config file. Since the modem works fine
without setting this pin, remove the logic to handle the W_DISBALE pin.
If the reset sequence fails, we don't want to transition to the powered
state, instead we should stay in the resetting state so we eventually
timeout and try a gpio reset. If the reset command succeeds the modem
will eventually send RDY and transition the state to STARTED.
Since this might take longer to change the modem state, add 15 seconds
(for a total of 45) to the at reset timeout just in case. It looks like
the modem typically takes about 20 between sending "AT+CFUN=1,1" and
receiving "RDY", so this should be plenty.
If the modem doesn't respond to the at reboot sequence, this will
attempt reboot the modem using both the power pin and then the reset pin
in case that doesn't work.
This splits the logic from gpio_check_poweroff into two separate
functions, allowing the caller more control over when the reset line is
asserted to force the modem to turn off.
Previously if the modem didn't respond to the power key sequence in
quit_app, gpio_check_poweroff wouldn't set the reset pin, and
eg25-manager could leave the modem running after exiting.
It seems `off_t` is now 64-bits wide on 32-bit architectures, so using
`glong` causes a build failure in this case. Switch to using the correct
type from the `sendfile()` prototype to fix this.
`!=` doesn't seem to be the exact inverse of `==`. To prove this I added
the following to the udev rules. On a system with the community firmware
both COMM_FW and NOT_COMM_FW were set to true, with the quectel firmware
only NOT_COMM_FW was true.
ATTRS{serial}=="community_fw", ENV{COMM_FW}="true"
ATTRS{serial}!="community_fw", ENV{NOT_COMM_FW}="true"
When using the community-maintained firmware, some attributes need to be
set with different values than what works best with the stock firmware:
this is the case of the `power/control` attribute which should be set to
"on". Similarly, on the PPP `power/persist` should be set to "1".
This commit reworks the udev rules so we can differentiate between
firmwares and host devices.
`doc/meson.build` used currently-deprecated functions. Replace those
with the proper alternatives, which were introduced in a newer meson
version than our requirement. As a consequence, bump minimal version.
BH PinePhone don't have the modem's `STATUS` pin connected to the SoC,
and as such require using `libusb` for checking the modem power state.
We didn't handle this case previously due to lack of on-device testing,
causing BH phones to fail with newer versions.
This patch ignores the `status` GPIO for devices relying on `libusb`,
which are only pre-CE PinePhones.
PP 1.2 and PPP configs were lacking this parameter. Although it's not a
problem as `eg25-manager` will then use a default value, adding them
won't harm and make them more consistent with other config files.
`modem_reset()` can be called from multiple places, both tied to a
specific timer. In order to prevent calling this function multiple times
in a row, disable all related timers as soon as we enter this function.
When going into firmware upgrade mode, the modem comes back with
different IDs than in normal use. We should make sure we cancel the
reset sequence when that happens, and not start a new one.
Cancel reset if modem is back before reset sequence is started.
When upgrading the modem through fwupd, it will enter fastboot.
Therefore, it disappears from the USB bus for a few ms.
However, the eg25-manager considers this as an issue and
resets the modem a bit later during the upgrade process.
To avoid this, cancel the reset sequence if the modem is already
back before the reset sequence is started. This will take less than 3
seconds.
As the modem is connected to a dedicated audio codec, we can select any
sample rate. Let's go for 16K as it should improve call audio quality.
Note: the bitclock's frequency is left untouched due to a bug in the
EG25 kernel, so we can't take advantage of the recommended higher
frequency.
The problem addressed by monitoring the modem status through udev seems
tied to the specific USB controller used by the A64. On RK3399 devices,
this quirk is apparently unneeded, and actually harmful as it resets the
modem USB connection while ModemManager is already configuring it.
This commit adds an optional config parameter for disabling this module
(enabled by default).
The timeout was meant to give more time to find the modem, yet the
callback didn't actually check if it came back but blindly issued a
reset.
Add a check to the callback to see if the modem was found and only
reset if not.
Fixes https://gitlab.com/mobian1/devices/eg25-manager/-/issues/28