ModemManager and GPS devices

[Aleksander Morgado]

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?

-- 
Aleksander
https://aleksander.es