ModemManager and GPS devices

[Tomas Jura]

Hi

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.

Thanks

Tomas