ModemManager and GPS devices

[Tomas Jura]

On 15.6.2015 18:13, Aleksander Morgado wrote:
> On Sun, Jun 14, 2015 at 9:48 AM, Tomas Jura <tomas.jura1 at gmail.com> wrote:
>> I have Ericsson modem F3507 with the GPS. For a long time I was using it
>> with the modemmanager and a control tool called mbm-gpsd which was handling
>> the GPS (ttyACM02) port. It was working together somewhat. Most problems
>> were during the start-up and restart when two different daemons (mm and
>> mbm-gpsd) were pushing together the setup AT commands to device. So startup
>> was a bit tricky, first start mm and let device initialize, then start
>> mbm-gpsd. It was working, but not smoothly.
>>
>> Mbm-gpsd has a very simple, but very well working solution to publish GPS
>> data. It creates  pseudoterminals (a pseudo tty), that it feeds by raw GPS
>> NMEA senteces. NMEA sentences are well known and widely supported protocol,
>> most of navigational sw understands them. I use that configuration with
>> OpenCPN and Navit applications. It also provides dbus api to set up gps
>> cycletime and assisted GPS.
>>
>> I found that GPS in F3507 got supported in mm ( commit
>> 534eea345dd8dda96a88559b621ab1a55028cee8 2015-04-08). But how to connect it
>> to existing applications? I see several options how to get GPS data from
>> device. I want to know your opinion about the right way.
>>
>> First of all I understand that mbm-gpsd will be eliminated. There must be
>> only one daemon to control the device, otherwise it will be mess in a device
>> configuration. I do not like eliminating mbm-gpsd idea very much, because it
>> has a nice gui (mbm-gpsd-control) and good control of gps ( GPS cycletime,
>> assisted gps https://en.wikipedia.org/wiki/Assisted_GPS ).
>>
>> Here are the solutions:
>>
>> 1. Extended the modemmanager so that it will provide a pseudo terminal with
>> NMEA sentences.
>> Pros: Easy to implement, simple solution. There is a nice example of a
>> working code in mbm-gpsd. Can be extended so that the mbm-gpsd d-bus api
>> will be fully supported and existing client can be reused.
>> Cons: IMHO not a systematic solution. Publishing the GPS data over
>> pseudoterminal has limited number of clients ( = number of created
>> pseudoterminal devices ).
>>
>> 2. Improve the clients so that they will understand mm dbus location
>> protocol.
>> Pros:
>> Cons: Very laborious. Non systematic solution, we need a common protocol for
>> GPS data publishing. mm dbus Location protocol is limited.
>>
>> 3. Improve gpsd daemon (http://www.catb.org/gpsd/), so that it will
>> understand mm Location protocol. Gpsd provides a common, well supported
>> protocol to provide GPS data from different devices.
>> Pros: Nice systematic solution which allows integration with other GPS
>> devices. No limits of GPS clients.
>> Cons:
>> - Another daemon which has to be running to get GPS data.
>> - Implementation of special features ( GPS cycletime, assisted GPS ) needs
>> implementation on both sides (laborious)
>>
>> Do you see other pros and cons or may be another solution? The right
>> solution is 1 or 3.  #1 seems to me as the most feasible solution.
> ModemManager allows one thing called "unmanaged gps", identified by
> the source value MM_MODEM_LOCATION_SOURCE_GPS_UNMANAGED. In this mode,
> a user can request ModemManager to control the AT port and configure
> GPS (i.e. enable, disable....), while leaving the NMEA TTY untouched
> so that other applications can use it exclusively. This solution is
> (should be) totally equivalent to what you suggest in #1. Instead of
> creating a new pseudo terminal we just allow applications to use the
> one exposed by the modem. Would this help?
>
Hi

The Alex's solution works! Thanks Alex. During the last week I spent 
some time to get it work. I finished with the following startup script:

#!/bin/sh
set -e
MODEM=$(mmcli -L |sed -ne '/F3507g/ { 
s!.*/org/freedesktop/ModemManager1/Modem/\([0-9]\+\).*!\1! ; p ; q }')
if [ -z "$MODEM" ] ; then
     echo "no modem F3507g found ( tested by mmcli -L )" >&2
     exit 1
fi

M="mmcli -m $MODEM"
$M --enable
sleep 1
$M --location-disable-gps-unmanaged
$M --location-enable-gps-nmea
sleep 1
$M --location-disable-gps-nmea
$M --location-enable-gps-unmanaged
stty -F /dev/ttyACM2 115200 raw min 5 time 100 iexten -echo -echoprt 
-echok -crterase

I had to start the modem in the regime gps-nmea and then switch to 
unmanaged. Direct switch to gps-unmanaged did not worked for me.
The final step was switch of the line discipline to a raw mode.

Compiling MM from git source code I had to apply the following patch:
diff --git a/configure.ac b/configure.ac
index a5f8d82..3290737 100644
--- a/configure.ac
+++ b/configure.ac
@@ -291,7 +291,7 @@ AC_ARG_WITH(qmi, AS_HELP_STRING([--without-qmi], 
[Build without QMI support]), [
  AM_CONDITIONAL(WITH_QMI, test "x$with_qmi" = "xyes")
  case $with_qmi in
      yes)
-        PKG_CHECK_MODULES(QMI, [qmi-glib >= 1.13.4], 
[have_qmi=yes],[have_qmi=no])
+        PKG_CHECK_MODULES(QMI, [qmi-glib >= 1.12.6], 
[have_qmi=yes],[have_qmi=no])
          if test "x$have_qmi" = "xno"; then
              AC_MSG_ERROR([Couldn't find libqmi-glib. Install it, or 
otherwise configure using --without-qmi to disable QMI support.])
          else

Tomas