ModemManager and GPS devices

[Marc Murphy]

Hi Thomas,
I use MM with different modems and the preferred interface to configure and get data is to use the dbus interface.  It is fairly simple and reasonably quick.
I can send you some sample code if you like or just look at the nmcli code as that uses all the dbus interfaces to talk to MM.

I would write my own process that probes MM and then publishes the NMEA sentences on a pseudo interface for you apps to connect to.

Cheers
Marc


> -----Original Message-----
> From: ModemManager-devel [mailto:modemmanager-devel-
> bounces at lists.freedesktop.org] On Behalf Of Tomas Jura
> Sent: 14 June 2015 17:49
> To: modemmanager-devel at lists.freedesktop.org
> Subject: ModemManager and GPS devices
> 
> 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
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel